Good enough August 26, 2026

Over the years, I have heard people argue about engineering excellence and code quality many times. Does it really matter? Who cares about the code quality of the umpteenth enterprise CRUD web app if it does the job? If it works, it works, right? Should I as an engineer really put in the effort to refactor the codebase to improve internal quality? It seems to be extra work with little benefit to anyone. Why argue about a method name? Who's going to pay for that? An 80% solution is good enough. No need to be perfectionist about it!^[1]

In my own experience, delivering 80% quality often is good enough. I have received compliments on occasions where I felt I could have done better. And I think it was OK to leave it at that. I still disagree strongly with the stance that this should be the norm. In my opinion, you should always strive for excellence, while accepting that you will not always achieve it.

To be clear, by performing at 100% I mean designing for and building towards the software's quality attribute requirements to the best of my ability. I'm not advocating for over-engineering in the sense that every internal app with 5 users should be scalable to millions, every JSON file should be replaced by an event-sourcing solution or anything like that.

For the purposes of this post I'll conflate the notions of delivering X% quality and performing at X% because I'm looking at the quality you are able to achieve, not some absolute measurement. Obviously, this will differ between engineers. The output quality of an experienced engineer performing at 80% might well exceed that of a junior performing at 100% of their ability, but it will still be only 80% of their personal quality ceiling.

Back to my point: I disagree that settling for 80% is OK most of the time. My disagreement is rooted in three observations, the first being that nobody performs at 100% of their ability all the time. This is simply not possible. So I will sometimes produce only 80% of the quality I am capable of normally. Since this is good enough in most cases, no worries, right?

But here's the second observation: excellence is a habit. It needs to be maintained, otherwise it's lost.^[2] If I don't regularly perform at 100%, after a while I will no longer be able to. As a consequence, if I decided one day that delivering 80% quality was “good enough” in most projects, I would sooner or later lose the ability to deliver my former 100% quality. This means that

1. I would no longer be able to take on projects that actually require 100% quality and
2. I would fail to clear the 80% bar from time to time, too, because 80% would now be my peak and nobody performs at their peak all the time.

So to get 80% quality from me consistently, you have to let me perform at 100% most of the time, even in cases where this is not necessary, strictly speaking. And if a project comes along that requires 100% of the quality I am capable of, I can deliver it successfully, too.

The third issue I have with the “good enough is good enough” stance is the implicit assumption that there is a trade-off between quality and speed. This is wrong for two reasons. First, the perceived speed boost that can be achieved by skimping on quality is short-lived, as explained, for example, here and here.

Second, and this is a factor I haven't read much about elsewhere, many (but not all) aspects of writing high-quality code don't actually take extra time if you have practiced them enough. For example, if you've built the habit of choosing good, expressive function names, this doesn't take any longer than choosing bad ones. Once you have developed an intuition for how to split complex functionality, you do it automatically. Putting a class in the correct package is just as fast as putting it in the wrong one. These are matters of expertise, not of extra “quality effort”. This also means that if an engineer spends time on such issues because the effortless expertise is not yet present (or has decayed), this time is not primarily being invested in the increased quality (which might not be needed right now) but in the expertise of the engineer.

So if you care about quality at all – even if only “good enough” quality – strive for excellence!