Thursday, June 17, 2010

The only design pattern is small solutions

I just saw this TED talk (which you need to see too!). It's essentially about how we prefer big complex solutions to any problem we face. Why? Because it makes us feel smart and important. As my head is filled software thoughts, I started to think how this it relates to software design. We software developers really!, really!, really!, like big solutions to small problems: "Oh, you got a program that needs to store some data? You better get yourself a dedicated database machine, a persistence layer, and define a XML schema for communication data format."

We don't need big solutions to small problems. Big solutions are easy to find. Big solutions need man-hours but no understanding. We need small solution to big problems. Small solutions are hard to find. Small solutions need insight into the actual problem we're solving. The actual problem is what's left when we remove all accidental complexity, marketing buzz-words, etc, and think clearly about the original problem.

Small solutions are orthogonal to each other; big solutions are not, they interact in non-obvious ways. Thus, big solutions creates more problems, or as the american journalist Eric Sevareid, said:
The chief cause of problems is solutions
which is more true in software development than in most other areas. Implement small solutions to problems and your future self will thank you. Implement big solutions and you fall for the sirens' calls of the marketeers, or your own wishes to do seemingly cool stuff while looking smart doing it. Do you really need a DSL? A database? Web interface? Reflection? Operator overloading? Meta-programming? Code generation? Ruby? SOAP?

Thinking small have big impact.

3 comments:

sud said...

Sometimes the solution to a problem is a set of small solutions wired together. For example, instead of one monolithic web application it may make sense to construct small dedicated components that are wired together to get the job done.

In the quest for simple solutions lets not over-simplify to where we are not building the right solution.

Togge said...

I agree with yo that aiming only for small solutions may cause us not building the right solution. I think the risk of doing that is much smaller than building over-grown solutions, though.

Fabien Bouleau said...

I more than fully agree with you. It converges with the KISS design principle (Keep It Simple and Stupid). The only thing to keep in mind is to build your solution in a flexible enough manner, in order to make it evolve if ever needed. And that's what makes the difference between programmers and software engineers...