Does Code Quality Still Matter? Max Kanat-Alexander Says It Depends on Whether the Software Is Disposable or Durable

Kanat-Alexander opens by joking that he picked a topic nobody has opinions about, noting that social media takes on code quality are deeply nuanced.

He points out that senior engineers answer nearly every question with "it depends." He says that answer is not very helpful unless the speaker explains what it depends on.

Kanat-Alexander asks why code quality ever mattered in the first place. He says that people often justify it by saying it made them feel good, which he calls an insufficient justification.

His stated goal is to inject some nuance into the discussion and give listeners a basis for reasoning about code quality.

Kanat-Alexander says that everything one wants to accomplish with software, whether aligning a model, scaling a system or driving adoption, depends on two factors and two factors alone: understanding, and executing on that understanding.

He says debuggers, observability, evals and even tests exist to improve either understanding or the ability to execute on it. In his view, all work in code quality serves only these two things and has nothing to do with correctness as a separate goal.

Kanat-Alexander says product and sales roles require other understandings, but for software engineers the two most important are the ones he names.

The first is the actual behavior of the system, meaning what it concretely does rather than what the documentation says it does. The second is how to modify that behavior correctly and safely.

For a very small system, understanding is simple: a program that prints hello world can be understood just by knowing what it prints, and changing it to print hi world requires little more than that.

Real software is different. Kanat-Alexander shows a map of the codebase of Chromium, the open-source project behind Chrome, and says that the ways its components interact produce essentially infinite possible behaviors. He says he could not describe the behavior of Chromium as a whole system in words.

What can be described, he says, are individual components. He uses the URL parser, the functions that split a URL into its different parts, as an example of a component whose behavior can be explained.

Kanat-Alexander explains that the whole reason code exists is structure. He compares two programs that both print Hello World on Linux. One has the identity and structure of a recognizable Hello World program, while the other is a series of instructions with no understandable identity or component.

He says the unstructured version would be much harder to grasp at the scale of millions or billions of lines. He argues that concepts such as readability and testability were stand-ins for what mattered most, which was that the system had an understandable structure.

Kanat-Alexander says every modification to a system carries two categories of risk. The first is introducing some kind of problem, and he defines a problem broadly as anything bad, such as a project taking much longer than expected, a system not behaving as users want, or budget overruns.

The second is making future changes harder, which in his words means making future problems more likely and increasing the future risk of the system. He says both risks are caused by problems with understanding.

Kanat-Alexander says the two risks reduce to difficulty understanding the system in the first place, and making the system harder to understand. He says he can reduce every postmortem he has read for any incident to these two factors.

He gives examples: a production configuration that was too hard to understand, something made impossible to understand, and emergent properties of the system that were impossible to understand.

He says the second factor feeds the first in a vicious cycle, and that the difficulty of understanding compounds over time rather than growing linearly. Eventually, he says, all systems reach a point where every modification involves some kind of problem, and he describes giant mainframe codebases where that is the case.

Kanat-Alexander notes that many arguments hold that future models may fix the complexity problem. He says maybe they will, possibly with an infinite ability to deal with complexity, but he chooses not to discuss that today.

He argues that models are doing something more interesting right now: creating a new category of software that has always existed but is about to become a hundred thousand times more common than any other form of software. That category is disposable software.

Kanat-Alexander describes a world in which the consequences of failure are minimal or nonexistent, few people depend on the software, almost no other systems depend on it, change management is minimal, replacement costs are near zero (replaceable in hours or days) and maintenance cost is basically nothing.

In that world, he says, code quality does not matter, because the compounding risks over time that quality is meant to prevent do not exist.

Kanat-Alexander says that traditionally software has been durable: it lives for years, is depended on by thousands or millions of people, carries huge consequences of failure, and requires enormous maintenance. Most software engineers spend most of their time maintaining these giant durable systems.

He expects durable systems to remain probably the most important systems in the world, and says there will likely be more of them. However, he says the most numerous systems will be disposable software. Examples he gives include fixing a calculator on your operating system or writing a party planner for a single party.

Kanat-Alexander says that in the future engineering rigor will be applied according to the degree of a system's disposability. At the disposable end none of the practices matter, while at the durable end the engineering practices built up over decades matter greatly.

He says the position on this scale can be judged by four factors: consequences, cost of replacement, dependencies and cost of maintenance. If all four are low the software is disposable, and if all four are high it is durable. He advises that anyone who has written software for a long time should err toward durable, meaning all four factors should be assumed higher than expected.

He also describes a new option: making software more disposable. Ways to do this include better isolated environments, such as deploying only to an environment with access to just your own data and no customer or personally identifiable information, and enforcing independence by disallowing inbound API calls from other production systems. He also mentions keeping an old, clunky but durable backup system so people can build their own more efficient front ends, knowing the front end may fail without serious harm, and limiting scope.

Kanat-Alexander says there is much more to discuss about increasing disposability. He describes it as a whole new discipline of software engineering: not how to improve the rigor of durable systems, but how to make systems encourage disposability so people can throw them away.

He stresses that durable software engineering is not going away, which he calls the biggest confusion he sees on social media. He believes the absolute amount of durable software will increase because AI coding tools make it easier to produce durable software.

He adds that disposable and durable are a spectrum rather than black and white, and that what changes across the spectrum is how much effort goes into engineering rigor, both immediately and over time.

Kanat-Alexander says that what people should care about most is reducing the cost of effort, and the cost of rigor in particular. If rigor is cheaper, the less one has to worry about where a project sits on the disposable-durable scale.

He gives an example: if you thought a project would be disposable and it turns out to need to be durable, a low cost of rigor makes it much easier to change course. He says no one is ever 100% right about such estimates. He says the practices that reduce the cost of rigor are a different set from engineering rigor itself.

He says he could talk about this for hours and that he has spent a large part of his career on it, and then runs through several areas within the time he has left.

Kanat-Alexander says standardization removes possibilities. If a system has no PHP, nobody has to work out which linters, practices or security holes apply to PHP. Standardization eliminates those possibilities and reduces the cost of rigor.

He applies the same logic to frameworks and protocols. Having every front-end or back-end framework in existence makes rigor more expensive. Rigor remains possible, he says, and an agent could still set up all the tools, but that has to be done every single time. He gives standardized RPC protocols as another example.

Kanat-Alexander calls tooling that just occurs inward-flow tooling. The programmer does not have to choose to run it or understand how it runs. He says it must be reliable, with very few false positives, and fast. If it is free and fast, he says, it can also be applied to disposable software.

On testing, he asks how to make it so nobody has to think about doing better testing and every test is fast and deterministic without anyone having to be a deep expert. He says that takes a lot of work on test infrastructure. He says he had long hoped every team would provide in-memory fake versions of its services so tests could run against them, and notes that a coding agent can now do that, though someone still has to choose to do it and make it available to everyone.

Kanat-Alexander says maximum strictness means turning strictness up everywhere, setting all lint rules to maximum and never compromising. He says it is similar to standardization in that it eliminates many conversations.

He acknowledges that sometimes the lint is wrong. As long as the false-positive rate is relatively low and there are no catastrophic consequences, he says that does not matter, because it removes a lot of future lint errors and issues. He says turning on a linter late in a million-line codebase can mean a 100,000-line change, so it is much easier to do it up front for everyone.

Kanat-Alexander says the framework lets him answer not just "it depends" but yes or no. For disposable software, code quality does not matter. For durable software, it does. He then answers a third question he calls more interesting: does rigor have to be expensive? His answer is no.