Three ways to solve a problem

In software development and perhaps more broadly, in creative endeavors in general, rarely does one solve a problem that has only one possible solution. Mostly there are “more ways than one to skin a cat”.

There is the “wrong way” which causes more problems than it really solves. This is usually where the newcomer goes wrong. Lacking experience with both the environment and tools, the inexperienced is fighting an uphill battle understanding both the problem and the consequences of a proposed solution. The fun part is that in an environment with good testing and feedback, this can actually be one of the quickest way to get problems solved.

Fail fast.

Then there is the striving for the unobtainable “perfect solution” to a problem. This is usually the “lightly trained” or “slightly experienced” Achilles heel. Having spent enough time in the trade to see that there are “bad” solutions, the pursuit now goes for the perfect “good” solution. This leads to analysis-paralysis and in software development usually over engineering. This will usually be the slowest and the most expensive solution/way to solve a problem.

The third way is the “least bad” solution. This is where experience makes it mark. Having enough experience to identify “really bad” solutions, but also the confidence and full overview of the problem, to not chase a non-obtainable perfect solution.

The sweet spot is usually the “least wrong” solution.

The one which solves the problem in a good way while not closing too many doors, but on the other hand not trying to keep all thinkable doors open (over engineering). This is of course in no way an easy feat. Trying to find the “least wrong” solution can be as exposed for over engineering and analysis paralysis as the “perfect solution”.

Even more annoying is the fact that you will probably only really be able to see a clear difference over time. But hopefully over time and with experience you will also be able to recognize where you created a solution that fits either of the three above scenarios and hence progress towards “less wrong” solutions.