On Code Quality

Debunking 3 Myths

Zillions of lines of code form the core of everything technological. From web-services like Google. To the controller on your fridge. To the auto-pilot that navigates an Airbus A380. A vast interconnected graph of “programmes”. Calling each other, and doing all manner of miracles.

Computer scientists differentiate “What the code should do” from “How well the code should do that”.

For example, “what the code should do” could be returning a bunch of search results after the user types “define: code quality”.

“How well the code do that” could include “the speed of returning search results”.

These two aspects are known as “functional” and “non-functional” requirements. The quality of software (or “software quality”) is also split into these two groups: “functional” and “non-functional”.

The terms “software quality” and “code quality” are often interchangeable. Though usually “software quality” is a “macro” description — referring to the entire system or product. While “code quality” is a “micro” description, referring to individual bits of code.

While code quality is an important topic, many myths surround it.

Myth 1: Code Quality has an absolute bar

It’s easy to define an absolute bar for code quality. It’s much harder to find the correct bar.

Writing high-quality code has benefits. A better customer experience. A better quality system or product. Fewer bugs.

Unfortunately, it also has costs. It requires better computer scientists. More tests. More testing infrastructure. And longer development cycles.

How you tradeoff cost and benefits depends on the nature of your product, system, and ultimately business. For example, if your product is free (e.g. Facebook), your users (probably) can tolerate a lot more bugs than an enterprise product (e.g. Facebook AdsManager). If your product is a even higher precision — higher safety system (e.g. a Flight control system), your tolerance for bugs is even lower.

Hence, you need to adapt your philosophy towards code quality based on what you are coding. There is no point in having Flight control system code quality on Facebook or vice versa.

Myth 2: The Best Code has Zero Bugs

It is relatively easy to reduce bugs. More testing, more detailed code reviews, and more QA people will usually reduce the number of bugs. The problem is that all these things cost money.

A good coder can reduce bugs. A great coder can move the bug-cost curve.

Great Coders figure out ways to have fewer bugs at the same cost. Or the same number of bugs at a lower cost.

Myth 3: Improving Code Quality is solely about Improving Code

A good coder does zoology. A great coder does ecology.

Let me explain the biological analogy.

A good coder tries to improve code quality by improving coding and the code. This is like zoology because code is like an organism. And zoology studies organisms.

A great coder, on the other hand, tries to improve the whole ecosystem. Multiple organisms include many coders and many lines of code. They build better testing frameworks. They institute better code review processes. They create code quality tools.