Generic solutions and simplicity

I have been writing software professionally since the early nineties. I used to favor pure generic solutions. For example, if I had had to write a program that was to save the Earth, I would have made it generic enough, so that it could save the whole class of planets similar to the Earth. Or with just a little bit of specialization – every single planet in the universe. Or even every celestial body in the universe! See the problem yet? At one of my previous jobs this habit of mine finally peaked and the serialization library that I wrote while there was so generic that user-defined types – ready for it? – virtually serialized themselves. No? Oh, well. Actually, the "virtual" part was due to the limitations imposed by the legacy code. Otherwise the implementation would have been entirely generic, which modern C++ is so good at.

Of course, so often by the time you finish your fantastic "celestial body saver" you realize that the universe isn't really worth saving. Or that someone else has a better solution. It's not like I no longer believe that generic solutions are awesome and save you a ton of future effort, but this imaginary future might never come. So instead of worrying about the whole universe of problems, why not focus on the specific problem at hand while keeping in mind how the problem can exacerbate? Is other words, it is important to know when to stop. I believe it was Albert Einstein who said that everything should be made as simple as possible, but no simpler. These words are golden! I wish I understood the full meaning earlier.

Some people argue that complex tasks are inherently complex and require complex solutions. In fact, they add, you might even want a certain amount of complexity in your solution to counterbalance the complexity of the task itself. I don't know what they mean by that, but it's clear to me that the goal of any solution should be to embrace the "maximum meaning with minimum means," as Abram Games aptly put it. Applied to software development this would mean that you should include in your application as few features as possible, but not fewer. Just enough to solve the problem. Not those proverbial 20% of the features for 80% of the people, but the minimum number of features that solve the maximum amount of the problem.