The Pitfall of Over Design (form before substance)

So there is a problem that needs a solution.

A specification is created for what the solution needs to achieve.

While the specification is being implemented it is noted that it is part of a more general solution.

The designer decides to implement the more general solution. If this is a software solution there may be many motivations to do this:

• produce code that can be reused in the future
• give flexibility for design changes
• general solutions may be more efficient and beautiful than specific

So the designer abstracts the solution. But in so doing they seemingly innocuously get drawn away from the original problem.

It seems harmless.

But unwittingly they are no longer bound by the solution, but by whatever motivated their decision to abstract.

Quickly the demands of the abstract solution take over from the actual problem that they set out to solve.

And the danger of this is that those concerns can amplify and become much greater than the original problem.

Quickly "form" can take over from "substance".

Another trivial and silly example might be someone who sets out to create a shopping list. They decide at some point that it would be better to organise the shopping list in terms of the isles at their super market. So they deviate to find a floor plan of the supermarket. Then they realise they may go to more than 1 shop, so they take floor plans of all the shops they may visit. And then decide that they may as well do this properly and do it for all possible supermarkets. Perhaps they sit down to start writing an app.

A week passes and the food shopping is still not done. They go hungry. The substance was food, the form was the structure into which getting food was forced. And the structure took over from the form.

The point of this blog is to identify the subtle error in abstracting problems away from their specific application.

It seems like a harmless and clever thing to do. But the moment we leave the concerns of the original motivation for a solution we lose the compass and the task can become unending and solutions become ever more abstract.

What then happens far more often than it should, is that the final beautiful abstract and general solution doesn't actually fit the specification. Some small detail was missed and this exception or boundary condition breaks the general solution.

You might think a general solution has more "solving power" than a specific. But often we get to the general solution by ignoring exceptions. Or we don't anticipate exceptions. So we make a net that is larger and casts far wider than we needed and then realise that the holes are too large for a particular type of fish we needed.

Stick to the original motivation for a solution will ensure that the right balance is found between general and exceptions.

However to enable future code use SOLID principles are useful. If we break even our specific solution into single responsibility functions we will find building a new solution in future much easier.