Problem Design Influences

When designing software, we are trying to solve some problem at hand. That problem could be as simple as writing a command line utility that does nothing more than export a database table and send it somewhere. It could also be a very complex problem involving the simulation of another complex system that exists in the real world. The more complex the problem, the more effort that is needed for designing the solution. The question is, to what degree is the design complexity influenced by the complexity of the problem?

One great feature of object-oriented software design is the ability to look at a problem from a reductionist perspective. We are free, as developers, to create abstractions at any level of specificity. The ultimate goal in software design being to take a complex problem and make it a little more understandable and approachable by designing abstractions. This provides a view into the problem from many different perspectives.

You almost never hear about great software designs for trivial problems. This is because the implemented solution is in fact trivial and takes no time at all grasp logically. Instead, you hear about how very large, complex problems were tackled and the end result was an elegant implementation. In these implementations, you're likely to find some abstractions that you don't see every day. This is because it wasn't an every day problem; the problem had a positive influence on design. The design is interesting because it is simplistic relative to the daunting problem it solves.

So does this mean that simple problems and simple solutions are any less interesting? I tend to think not. Simple problems weren't always simple. Over time, they turned into simple problems by being removed from a larger problem. It might make sense to re-evaluate whether or not you are in fact trying to solve the right problem before it becomes a complete glutton.