"As I'm becoming a more experienced programmer, I tend to prefer simple solutions." Or something similar. As is the case with many programming-related quotes, this is somewhat of a blanket statement because who doesn't prefer simple solutions? To make it a powerful statement again, you'd have to explain what a simple solution is, and how you distinguish it from not-so-simple solutions. So the million-dollar question is "What is a simple solution?", and I'll answer it now.

Just kidding. But I do have some ideas about this.

There are several aspects of simplicity we'd have to consider. For instance, we could consider simple solutions in programming to mean several things:

• Easy to use (e.g. a single method call, a single dependency, a single argument, etc.)
• Easy to understand (e.g. the logic can be grasped by looking at a single function definition)
• Requires the least amount of code (e.g. 5 lines of code instead of 100)
• Requires the least amount of classes, functions, etc. (e.g. 1 class instead of 10)
• Independent (e.g. no additional packages need to be installed)
• Easy to change (e.g. maintained by ourselves, not dependended upon too heavily)
• Allowing reuse of the solution in a somewhat different context (e.g. portable, not necessarily generic)

These properties aren't exclusive. What we consider simple solutions often expose several of them at the same time. There may also be others that I've missed here (of course). Still, this list could help us judge the simplicity of a given solution. We might even be able to quantify this simplicity. For instance, extending from a parent class would subtract 5 points from the simplicity score, because it imports quite a bit of code, adds a class to your solution, makes it less easy to understand because you have to jump to the parent class and figure out how it merges its behavior with the subclass, and on top of that requires an additional library to be installed. Considering all the downsides, the penalty might be a bit higher ;)

In the next few articles I'll cover several areas of programming where there's a debate about the best way to do something. E.g. for a model, should we use active record, or the data mapper pattern? For dependency resolution, should we use a container, or a locator? And so on. We'll look at each of the solutions from the perspective of simplicity, and calculate some kind of score for the competing solutions. If I'm not mistaken, you should then be able to calculate your level of programming experience based on those simplicity scores ;)