Much of my work consists of solving problems. Problems in areas such as the development process, cooperation between team members, software architecture etc. I’ve noticed there are roughly two ways to solve problems, using big solutions or using small solutions (for lack of a better term). A lot has been written about big redesigns etc. however, I want to understand where these big solutions come from. I think it’s our natural tendency to abstract situations which makes us favor big solutions, even though they’re not always the best option.

After explain the usual method I’ll give you some examples which you can probably identify with. The next post will discuss the small solutions and their gripes.

To clarify, in this post ‘fixing problems’ means fixing them in real life, not just analyzing the problem. The process that leads to **big solutions** is something like this:

- Get a clear overview of the situation
- Simplify the situation
- Fix the problem if it hasn’t fixed itself already (more on this later)

To illustrate let’s imagine the problem is picking all the green circles from this pile:

Now, the usual process:

1. Get an overview: place all the circles in a line:

2. Simplify the situation: Group the circles by color:

3. Fix the problem: it has almost solved itself as the green circles are on a separate pile. Now you might notice your mind altering between seeing all the different circles and seeing 4 piles. Just by sorting the circles by color the problem was fixed. Isn’t that neat? And now we can reason about the piles in stead of all the different circles, which makes life easier still.

**Abstractions**

A pile is an abstraction of the circles on that pile. In most situations it’s far easier to talk abstractions than the actual things you’re dealing with because otherwise the amount of detail would be overwhelming. That’s why we like big solutions, when restructuring the context of the problem, it becomes easier to reason about. For instance if everyone uses the same operating system it’s easier to reason about PCs in your workplace because you can forget about the detail of the operating system.

To make abstractions, there has to be some visible patterns in the situation, otherwise it’s just a big mess (like the single pile of circles). To get to a point where simple abstractions can be made, people go very far in restructuring the situation, often destroying value in the process. One important thing to realize is people don’t favor big solutions, big solutions are a result of our desire to abstract and simplify, it’s a natural tendency with adverse effects (in some cases).

This is the issue with big solutions. It’s not a bad strategy to deal with complicated problems, but big solutions don’t solve the problem very quickly, they start paying of usually months or even years later.

When simplifying the context of the problem, you could for instance introduce a new method: throw out all existing social structures and procedures and replace it with a full implementation of a method that is ‘consistent and correct’ throughout all layers of the organization. The big problem here is destroying the existing structures that worked very well or were even specially tailored to the domain. The biggest issue with restructuring is the new structure will have problems of its own. So by fixing one problem you could be introducing several others that come along with your new method.

I’ll give you some other examples of big solutions from my recent experience:

- IT department is slow and expensive, we’ll replace the entire IT infrastructure with an off-the-shelf product.
- Our process is too slow and complicated in places, we’ll redesign and document all business processes and put them all in a BPM tool.
- The use of one technology doesn’t fit certain problems in our application, we’ll refactor all modules in all applications to use a new technology.
- We’ve got a big pile of legacy systems, let’s define a new architecture (SOA) and demand all projects to conform to that architecture from now on.

I also tend to come up with big solutions. These big solutions, when you first image them, always have sense of elegance, simplicity and control. When struggling with the current system architecture I come up with things like: “If we could only replace the entire back end with technology X” or “If we could only get 6 months to make tests for all the legacy systems”.

But while you’re restructuring, training people in new methods and drawing up conceptual charts you’re not actually fixing anything. You’re laying ground work to fix the problem in one big sweep. It might actually work too, the big solutions are not wrong per se, they just distract you from the problem and a smaller solution would have had a far higher return on investment.

Do you explicitly think when to use a big or small solution? How effective are big solutions? In my next post I’ll talk about ‘small’ solutions and how they are a great alternative when you find yourself drawn to the big solution.

Nice write-up:

I think there are several ways to go to a big solution though.

What you described is the big bang scenario, but you could also go to the envisioned big solution is small steps. Important is that each small step contributes separately to the big problem that the big solution is trying to solve, so every small step is like a small solution.

@Lars Vonk

Indeed, small steps are good and small steps should add value. However, be sure to stop making these small steps when they stop paying off. In most cases that’s long before the big solution is fully realized.

I don’t think there will ever be time when it’s a good idea to have all your processes in a BPM tool or all your software working under the same architecture, simply because the cost of getting this ‘big solution’ is not worth it. More on this in my next post!