Perfection in the Context of Software Engineering

Perfection isn’t Worth It

Attaining perfection in software engineering is rarely ever worth it. This does not mean developers should not strive always make things better; but developers should not make perfection the enemy of progress and betterment. I believe it is important to acknowledge and accept imperfect pieces of work so that iteration and learning can happenat a faster pace.

Perfection is different for people

An interesting thing about perfection is that it may take a different shape depending on the viewer. In the context of a code review, is the code logically complete and tested? Is the code efficient? Did the author handle all the errors and exceptions that can happen? Is the code legible? These questions can be all be subjectively answered in any non-trivial code review. Depending on the review, perfection in one person’s view may be unacceptable for another viewer. We should be more accepting of contributions that bring us closer to perfection rather than blocking and demanding perfection every time.

Perfection is really really hard to achieve

In the Google SRE book, it talks about the concept of managing and embracing risk. The TL;DR of this chapter is “The cost of trying to build 100% reliable software, gets exponentially more expensive and time consuming the closer you get. Stop trying to reach 99.999% reliability when no one will notice the difference from 99.99%”. Sure, .01% or 0.001% of the time, something will fail and maybe something needs to be looked at. In some situations, maybe that’s not okay, but maybe it is? It will depend on you and your team’s judgement of the situation but there should be a discussion, rather than just accepting a body of work to fix.

But at What Cost

Why do I argue for being imperfect? Because I want to do and build other stuff. You want to do and build other stuff. In the time it took to take error rates from 0.01% to 0.005%, the team could have been working on an entirely new feature or product idea. A new experimental feature could have completed an iteration of evaluation and improvement. We could have been spending time making a big difference instead of a little one.

Accept good, accept risk, and build more cool stuff.

Disclaimer

I accept that these thoughts are more start-up velocity/delivery focused.