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 solutionswhich 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:
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.
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.
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...
Post a Comment