Problem-solving and the dirty dishes of software development

Some types of problems have a linear cost function. This means that if a problem is doubled, the cost to solve it is also doubled.

An example would be reading a book, or traveling — if it takes you one hour to read fifty pages of a book, then you can conclude that it would take you twice as long to read twice as many pages, or if it takes you one hour to travel a fixed distance, then it will take you twice as long to travel twice the distance (providing that you maintain the same average speed).

However, there are many problems where the cost function is nonlinear. In practice, this means that as the problem increases in size, the solution cost becomes disproportionately higher.

Dirty dishes principle?

Take for example washing dishes. If all you need to wash is one dirty plate right after lunch, it’s no big deal. But as soon as you have a sink full of dirty plates laying around for weeks, the problem becomes much more difficult than simply cleaning every single plate individually (unless you are using a dishwasher, but that is cheating).

All of a sudden, you have less free space in your sink, you need to be extra careful not to damage the rest of the dishes, you will probably need to do much more scrubbing and soaking as the dirt on the plates has hardened, and that in turn will require more soap, bacteria can form, etc, etc.

The goal of cleaning dishes suddenly looks unachievable and the task is not fun for anyone.

A bunch of new problems (which need to be solved, and now have a cost) emerged just by deferring and accumulating the problem and letting it increase in size. These problems did not exist when there was only one dirty plate. These problems would never have showed up had you washed every dish as soon as it became dirty.

I call this the dirty dishes principle and it maps very well to software engineering.

How does it transfer to software development?

Take for example the exponential cost of fixing bugs. If you detect a bug early on, as early as in the inception phase, the cost of fixing it is very low. The bug was not around for enough time to cause any real damage and you already know which part of the code needs fixing — the context is well known and understood, which all contributes to a quick and easy solution.

But if you fail to find the bug, and time passes — the problem becomes harder and more costly to solve. Now all of a sudden, you need to invest time just to figure out what and why is wrong. The bug probably caused some issues with customers, which damaged the product image and will negatively impact future revenue. The original author of the bug is months gone in a different company, documentation is scarce, no one knows how the code works, and you need a hero to save the day.

A bunch of new problems (which need to be solved, and now have a cost) emerged just by deferring and accumulating the problem and letting it increase in size. These problems did not exist when there was only one dirty plate bug. These problems would never showed up had you washed every dish fixed every bug as soon as possible.

This is exactly what happened to the pile of dirty dishes, and the best part is that it could have easily been avoided by investing in QA.

Another infamous example that clearly explains this principle is the Broken Windows Theory, which states that leaving a problem unattended will contribute to the problem becoming worse and thus more costly to solve. And this applies well to technical departments and singles out the importance of refactoring.

The point is — handle problems on time…

Software engineering is absolutely filled with these costly nonlinear problems. Be it code maintenance, system design, bug fixing, algorithms and many many others. That’s why it’s important to detect which problems have a nonlinear solving cost, and address them as early on as possible.

Do not let your problems accumulate, as the price of solving them could end up costing you more than the sum of its parts.

If you want to learn more about problem-solving and the importance of quality assurance, check out some of our other articles:

• How QA ensures your contact form won’t disconnect you from clients
• How QA expenses can be cheaper than having no QA expenses
• Behavior-Driven Development: how to find bugs before coding starts