What's the Right Level of Code Quality?
Companies have to decide what the right level of code quality is for them. Such decisions have two aspects: the cost, and the benefit.
Let’s look at the cost first. Code quality comes at a cost: you need to come up with code quality guidelines, discuss them in your team, get everyone to understand them. Then, whenever an engineer writes code, he has to keep these practices in mind. Then you may have a code review. During the code review, bad code is pointed out and needs to be improved. New engineers need to be adapted to your code quality. When you add all these together, it’s clear that code quality comes at a cost in slowing down your company, or in requiring more engineers to compensate, as this infographic shows:
Here, on a scale of 0 to 10, 10 is the best possible code quality, like what Google has. If you want more code quality, you have to pay more.
The other side of the coin is benefit: fewer bugs, not having outages all the time, being able to handle it if too many users start using the service too soon, avoiding breaking commitments to customers, having happy customers, avoiding a negative word of mouth, having a productive engineering team, and having happy engineers.
So, code quality has its costs and benefits. When we put them together and do a cost-benefit analysis, we end up with the value:
More code quality is not always better, despite what some junior engineers naively think. Non-technical founders typically understand this very well. They know they’re not Google, so they shouldn’t ape Google. It will be too slow for them.
But many non-technical founders err in the opposite direction: they have too little code quality, like 0 or 1 on the above scale. Then they wonder why their product is not scalable, keeps crashing, why customers are unhappy, why deliveries are not timely, why the engineering team is unproductive or dissatisfied, and other variations of these problems.
The appropriate level of code quality depends on what you’re doing. Say you’re prototyping a bunch of different ideas to show to potential users and iterate with them to eventually pick one.
In such a case, lesser the code quality, the better:
Conversely, say you’re working on a product that has 100 million users, or is safety-critical. Then you need a higher level of code quality:
Even in this case, the ideal code quality is 9, not 10. Even Google, at least the teams I worked with, had too much code quality. It once took me five weeks to add two fields to a dialog box, because of repeated iterations of code review that were rejected with trivial, subjective and inconsequential objections. Too much code quality will result in slow progress and engineers who are motivated to make a difference1 quitting.
So, understand what the right level of code quality is, and move to the right point on the curve, in order to succeed.
Rather than caring only about job title and salary.