"Solution-Probleming"

Ah, coffee!

Typical day - started without any food and the "right" hour was coming to get the first "warm" meal in this day - a coffee with a spoon of coconut oil.

Nothing gives you that kick of energy.

I went into the kitchen and immediately navigated to the drawer, where the coffee grinder has its residence.

"No coffee" was the status written as string on it (What am I talking about? Check Modeling Maturity Levels or The Value of Value Objects), so I grabbed some beans.

Damped them in the right place in the appliance, pressed the button and...Nothing happened.

No "bzzt", no mechanical squeaking. Almost like a tree, falling in the forest when no one is there.

Argh, no coffee!

After a quick inspection, it turned out that the coffee girinder's lid was broken. There should be a small, plastic cam.

Its main purpose was to work as a mechanical safety breaker that prohibited coffee grinding when the lid wasn't properly placed.

A picture with attached illustrative drawing of a plastic lid with a cam.

Turns out, that this small, plastic cam - wasn't there. Or rather - it was there partially, which caused malfunctioning.

An illustrative drawing of a cam and its function

So now, the mechanical button, working as a contactor, wasn't doing its job too.

My coffee time was about to collapse.

Trust me, I'm an engineer

I couldn't leave it with such a status - "BROKEN" - clearly written on the coffee grinder.

I started tinkering what I could to do solve this problem. I investigated the damaged cam and soon after that I found a missing piece of it.

"Ok, how can I connect it to entire lid?" - were the first thoughts of mine. Few seconds of happiness were destroyed after I noticed glueing isn't an option.

"It will soon be broken again" - was my observation.

"Is there any other option I can use to link it back to the lid?", I started exploring the solution space for my "disconnection" problem.

I got an idea - I could solder it back to the lid. I saw the pictures of victory, showing off with my soldering skills that can be applied to a plastic lid and a cam.

Immediately after that thought, I saw all the problems I could possibly have - going to the basement, finding the soldering iron kit, trying to solder it, etc.

Complexity almost creeped in!

"So maybe a lighter instead?", another thought appeared.

I didn't let the termal solution go. I felt how badly I clinged to it.

Trust me, I am a problem solver

I took a small break from debugging the issue.

Came back after few minutes and asked myself: "what problem am I solving right now?"

"A coffee grinder cannot be used, because the mechnical contactor cannot be pressed by a lid's cam", I restated the definition of the problem in my mind.

"If I could press the contactor, I would be able to prepare my coffee!", I envisioned in my head.

I followed this deduction with the next question: "what is the easiest possible way to make the contactor pressed?"

I had an idea.

What if I could put there a cut wooden stick for skewers that is used for tasty BBQ meals?

An illustrative design of a wooden stick for skewers working as a static cam.

It seemed easy and pragmatic.

I took one of the wooden sticks for skewers and cut it correctly to fulfill my engineering's vision.

After few seconds it was there.

A solution to the "broken lid" problem

Are we done?

But I didn't finish. The applied solution is only the half of the final solution.

What was left?

I was missing the new problems, created by my solution.

"What problems my solution has introduced?", I asked myself.

I thought of safety issues that might happen - like grinding with no lid.

Or taking off the lid before the grinding was done so that coffee will be everywhere, but not in the coffee grinder.

Had a bunch of other ideas but I immediately communicated the most risky one - not enough safety. So my wife acknolwedged that such temporary solution is just fine (she wanted to get her coffee too).

It might seem that entire journey took days, but actually it was less than 10 minutes.

Is it the best solution?

You might think "what the hell has just happened?" (I hope you do). A coffee grinder? A wooden sticks for skewers?

"I don't have time to read such a nonsense, I am a serious architect/developer/team leader" - such thoughts might arise.

During this short period of time we encountered several "phenomena" - I already wrote in this blog about some of them.

The first observation is how easily we fall into a trap of focusing on the solution, without understanding the problem we are facing.

Ideas around soldering and using a lighter weren't bad in their nature, but they involved so much accidental complexity.

Soon, the accidental complexity would have become "the accidentally essential complexity" (I wrote a bit about it in Essentially bounded, Accidentally unlimited).

I almost fell into this rabbit hole.

What's more, The King of Kings, the context, matters as well. If I lived on an island and without a possibility to get a new appliance - was my solution the best of all possible? (let's forget about not having electricity there, for a while).

Is it the final solution?

All the conditions - time of the day, future needs and ideas - made me thinking that it was the best suitable solution, in that context.

It's similar to our design in the software work - whether we are talking about the architecture of a particular system, or an organization of classes that are collaborating together to solve a given problem (An organization? You might be interested in "Organization-Driven Design" and in "Microoffices" vs "Officeolith").

Applied solution is so dependent on the contextual environment. As I wrote in I don't know:

Try to understand the context you are operating in.

Trade-offs? What trade-offs?

What we also could observe, is the trade-off juggling.

A wooden stick for skewers was solving the problem of the connector not fulfilling its responsibility, but it introduced some other problems.

In one of his great books, Are Your Lights On?: How to Figure Out WHat the Problem Really Is, Jerry Weinberg stated quite clearly:

Even if we find a perfectly viable "hammer" for a given "nail", it will create a set of new issues.

As with the example of losing safety features - it's not the best approach, but for that day of the coffee grinder breaking down, the clear communication was the key (it's always the key, just for your notice).

That's why it is so damn important to ask the fundamental question: "what problems do I introduce by applying X as a solution?" (if you are interested, I shared more of similar insights in Software Engineering for busy parents)

It might give you the perspective what is the impact of "this little tiny if down there".

Solution probleming?

There's another quote of Jerry, from the same book, I like very much:

It's easy to just go and think about the solutions, about the design, about the architecture, without putting enough time and effort for understanding the fundamentals, the context and the needs, about the problem we are trying to solve.

Jerry found a perfect name for such activity: "solution probleming".

When we lose the focus on the problem, its definition, we might become "a solution problemer". That's a handy alternative for describing someone who got trapped in trying to solve the solution's accidental complexity that he or she introduced.

React, Kafka, entangled setup of ocks, frequently breaking tests, using Event Sourcing, Cloud, rewriting legacy, wrong configuration, etc. - what is your problem? what are you trying to solve, really?

Another interesting question we might pose, to Slow down, is:

It sounds very trivial and even funny, but tinker about it for a while.

It's so easy to get "into the zone", "into the process", and have "skin in the game". Tunnel vision is right around the corner.

As we are talking about the tunnel, are your lights on?