This blog is focused on solutioning versus problem solving.
Most people seem to think these two are the same thing.
They are not.
Contents
What are problems?
Let’s dig into the idea of a problem as a reference point.
A problem is something that isn’t what it should be. Something doesn’t make sense, or perhaps it operates inefficiently. Something breaks or flakes or shakes the wrong way.
In general, problems can be solved from two directions: obviation (removal) or abstraction (acceptance). Everything in between is nuance of the two and can be boiled down to one or the other when an atomic unit of “problem” is reached.
And here’s where we see an interesting pattern in the world of software and platform development: by default, most engineers choose abstraction over obviation. I’ve noticed this over several years of building things with an observation of how engineers behave under a variety of situations.
The ratio isn’t even close; my gut says perhaps 90% of problems are immediately thrown into the abstraction bucket which is kinda INSANE. And, to be fair, it’s not always the engineer’s fault; many times leadership forces the abstraction choice and then gets upset when system quality degrades.
Why is abstracting a problem a bad idea?
Imagine a scenario where you have a car parked in your garage every night. You use this car for your daily commute to work and back.
Upon waking up each morning to make your commute, you turn on the garage light and notice a small pool of liquid has formed under your car. Thinking nothing of it, you go to work, come home, and the process repeats.
But now the pool of liquid has grown in size.
How do you solve the problem?
Using the abstraction process, you would find a way to automatically clean up the leak. I mean, that’s a solution, right? You could just ignore the problem entirely and build some automation to detect a leak, trigger a cleanup bot to go mop things up when a certain leak threshold is met, and then log the process for future troubleshooting.
That technically does work.
Being technically correct is worthless. People use systems, not technologies.
Windows Millennium tried doing the same thing with its memory management and, yeah, technically that operating system worked, too. 😁
This is why solutioning is not the same as problem solving. Yes, you have a SOLUTION, but you didn’t really SOLVE THE PROBLEM. In fact, you’ve now created a product (and not a very good one).
When all you really needed to do was obviate the problem.
Great architects obsess over simplified architecture
Abstraction creates complexity. Complexity increases fragility and flakiness of a system. Systems built this way cannot be made reliable, performant, or operationally efficient.
Complexity isn’t just expensive. It dooms a system’s lifetime.
Complexity robs a system of the ability to generate margin (in however you measure margin).
And so, let’s add another item to the list of What Great Architects Actually Do: they obsess over simplified architecture. We assume that complex is a bad idea and that simple is perhaps a good idea (but still requires validation).
And so our systems should remain SIMPLE, which yields systems that are potentially strong, reliable, performant, and easy to operate given the right ingredients and time.
Problem solving checklist focused on obviation
I use a Kata (型; form) in the list below to help with problem solving. I stole the idea from martial arts. Use a Kata to memorize and perfect the movements being executed to understand why problems exist and remove them. Repeat this form daily.
Rather than starting with a solution, start with the problem itself:
- Ask yourself: Why does this problem REALLY exist?
- Admit accountability: Something is broken between the logical chain of points that connect a series of tasks together. Hold yourself accountable to find the break.
- Action plan: Ask a ton of questions about this chain. Find the break.
- Adjust perspective: If you do not understand the chain, you do not understand the problem. Adjust your thinking and perspective and repeat the Kata.
In the case of the car, the problem isn’t the liquid leaking on the floor. It’s the leak itself. Something is leaking and breaking further up in the chain. That’s the actual PROBLEM.
Go fix that problem by obviating the leak with your team! And then you don’t need to abstract anything. The leak is now gone. The floor remains dry. High fives, team! Huzzah!
Wait, why is abstraction so popular?
In the imaginary scenario of the leaky car, the problem is more obvious. But also building little robots to clean up a mess on the floor is hard. Fixing the leak really is the path of least resistance.
It’s really really EASY to abstract problems with technology. And that’s the DANGER.
Easy automation is that dopamine hit that most engineers reach for, first.
- This is why Terraform has so many wrappers available when wrappers are a horrible idea (seriously)
- This is why people later inherit workflows that are complex and difficult to maintain or even understand with no power to fix them
- This is why it’s so impossibly hard to untangle the web of abstraction that exists for most enterprises today
- This is why we find so many cross dependencies between environments that are supposed to be in isolation from one another and have trouble trusting in Continuous Deployment
- This is why it’s HARD when it SHOULD NOT BE HARD
Because engineers continue to abstract and abstract and ABSTRACT.
And then you’re left with an abysmal experience for EVERYONE involved and having to maintain a Rube Goldberg machine for the next few decades.
Summary
In a 🥜 nutshell:
- Start with understanding the problem; REALLY understanding it (ask all the dumb questions you need)
- Then try obviation
- Else leave abstraction for extreme edge cases or as temporary loan on technical debt
Much love ✌
P.S. Send me an email (blog at this domain) with any questions or comments you have. I’ll pick any particularly interesting questions to respond to within a future post.
P.P.S. I’m going to start dropping small YouTube segments with additional thoughts (me ranting about vendors, rambling on about design, reviewing misleading content, sharing mind maps, so forth). Subscribe + enable notifications if you want to be the first to see what’s cookin’.
