Does Code Quality Still Matter? It Depends on This — Max Kanat-Alexander, Capital One

“It depends” is the senior engineer’s ready answer to whether code quality still matters. Max Kanat-Alexander of Capital One starts by asking what that answer depends on. Before deciding how much engineering effort to spend, we need a reason code quality mattered in the first place. Feeling good about the code is too weak a justification.

His framework starts with two requirements for accomplishing anything with software: understanding, and executing on that understanding. Debuggers, observability, evaluations and tests help us learn what a system does or act on what we have learned. The same model covers work as different as aligning a model, scaling a system and driving adoption. Code quality earns its place by supporting those two requirements.

For a software engineer, two kinds of understanding matter most:

• Actual behavior: What the system really does, including behavior its documentation may not capture.
• Safe modification: How to change that behavior correctly and safely.

For a program that prints Hello, World, understanding and execution fit in a tiny example. Its behavior is the printed text. Change the requirement to Hi, World, and the intended modification is equally easy to describe. There is little else to understand before making it.

The codebase map of Chromium, the open source project behind Chrome, introduces a different problem. Its components can interact in too many ways for a useful description to enumerate the whole system’s behavior. A component provides a smaller unit of understanding: Chromium’s URL parser identifies the different parts of a URL. That behavior can be described even when the behavior of the browser as a whole is too complex to hold at once.

The next Hello, World comparison asks what structure contributes when output stays the same. Both versions would print Hello World on Linux. The left-hand representation makes its identity as a Hello, World program apparent; the right-hand representation presents a series of instructions whose overall purpose is harder to recognize.

At this small scale, a reader can still work through the instructions. Across millions or billions of lines, the missing structure becomes much more consequential. Readability and testability are ways of talking about the underlying need for an understandable system. Identifiable components let us reason about behavior without repeatedly reconstructing their purpose from individual operations.

Changing a system creates two kinds of risk:

• A problem with the current change: The code might behave incorrectly for users, but the project can also run late, exceed its budget or fail. A bug is only one kind of bad outcome.
• More difficulty on future changes: The modification can make the system harder to understand and alter, increasing the likelihood of problems later.

These risks connect to understanding in different ways. Existing difficulty makes it harder to perform today’s change safely. New difficulty introduced by the change makes tomorrow’s work riskier. A confusing production configuration or behavior that emerges from complicated interactions can make the current system difficult to understand; a modification that obscures the system adds to that difficulty.

The feedback path below explains how one modification can raise the risk of later problems. A change can cause immediate trouble, and it can also leave a less understandable system as the starting point for the next change. Kanat-Alexander describes this as a nonlinear compounding effect. At the extreme, almost every modification creates a problem. His giant mainframe example illustrates the result: a system becomes difficult to change at all, with costs appearing in timelines and organizational problems as well as software failures.

Future models might become better at handling complex systems. Kanat-Alexander sets that possibility aside to examine another change: the expansion of disposable software. This category has existed for a long time. He expects it to become dramatically more common as models make software easier to create and replace.

Imagine a program with minimal or nonexistent consequences of failure, few users and almost no other systems depending on it. There is little need to coordinate changes with others. The whole thing can be replaced in hours or days, and maintenance costs nearly nothing. Under those conditions, preserving code quality has little value in this framework: the compounding risks it was meant to prevent no longer justify the effort of preserving the implementation.

Durable software carries a different set of obligations. It lives for years, serves thousands or millions of people, can fail in ways that threaten the business, and demands continuing maintenance. Kanat-Alexander expects these systems to remain among the most important software even if disposable programs become the most numerous. Their continuing need for changes keeps the value of understanding and safe modification high.

Two small examples make the difference tangible:

• A personal calculator: If the calculator supplied with the operating system is unsuitable, make another one. In the imagined world of cheap replacement, the few people using such a tool can have agents make their own versions instead of preserving one implementation indefinitely.
• A planner for one party: Build software to organize a party for the kids, use it for that event, then throw it away. The task ends with the party; the software does not need a continuing life as a maintained product.

To decide how much engineering rigor a system needs, compare four factors together. The endpoints of the spectrum are:

When all four are low, the system is disposable; when all four are high, it is durable. Cheap replacement addresses only one row of the table. These factors provide qualitative guidance, so mixed cases still require judgment about how much rigor to apply. The practical bias is conservative: err toward treating the software as durable, and assume each factor may be higher than it first appears.

Disposability is something engineering can increase. Four independent choices reduce the consequences or obligations that make software expensive to abandon:

• Isolate data access. Limit deployment to an environment with constrained access to the builder’s data, excluding customer data and personally identifiable information. The environment limits what the software can affect when something goes wrong.
• Prevent production dependents. Disallow inbound API calls from other production systems. Keeping those systems from relying on this one makes its deletion or replacement easier to tolerate.
• Keep a durable fallback. An old, clunky system can remain available while people generate more efficient front ends. When one of those front ends fails, its users can return to the old system. The new interface is easier to discard because the important work still has another route.
• Limit scope. Keep the calculator for one person or the planner for one party. Fewer users and a shorter useful life leave fewer commitments for future changes.

The fallback example makes the relationship especially clear: a durable backup and disposable front ends can coexist. The backup is what makes a front end’s failure tolerable. Kanat-Alexander proposes designing for this kind of disposability as an additional discipline of software engineering. He also expects AI coding tools to increase the absolute amount of durable software, because they make that software easier to create too.

Disposable and durable therefore describe a spectrum. What changes across it is the amount of effort worth putting into engineering rigor. A team can change a system’s position by reducing its consequences and dependencies, while still preserving durable systems where their responsibilities require them.

A second design choice changes the cost of rigor itself, both immediately and over time. A program initially treated as disposable may later need to be durable. The cheaper it is to strengthen that software, the less painful the mistaken estimate becomes. This creates a separate engineering task: reducing the effort required to apply good practices.

Several practices attack that cost in different ways:

• Standardize the choices that multiply support work. A system with no PHP has no PHP-specific linters, practices or security issues to manage. Fewer frontend and backend frameworks mean fewer sets of supporting tools to build. Shared remote procedure call (RPC) protocols serve the same purpose. An agent may be able to generate tools for every stack, but each additional stack creates that work again. Standardization reduces the number of possibilities rigor must cover.
• Put reliable tools in the workflow. Checks should happen automatically, without programmers deciding to run them or understanding their implementation. They also need to be fast and produce few false positives. Automatic but noisy tooling still costs attention; automatic, reliable tooling can feel almost free. At that point it can be reasonable to use it for disposable software too.
• Make fast, deterministic testing easy to obtain. The goal is for test authors to get these properties without becoming testing experts. That requires substantial work on shared test infrastructure. The concrete proposal is to provide in-memory fake versions of services, so tests can use those substitutes for their dependencies. Coding agents can help create the fakes, but someone must choose to provide them and make them available to everyone. Shared infrastructure lowers the effort each programmer must spend figuring out how to test.

The final recommendation is “maximum strictness”: turn lint rules up from the start and apply them consistently. Like standardization, this removes recurring choices and arguments. The tradeoff is accepting some incorrect warnings when the false-positive rate stays relatively low and their consequences are tolerable.

The cost becomes obvious when a large codebase adopts linting late. In Kanat-Alexander’s illustrative example, turning on a linter in a codebase with a million lines creates a cleanup touching a hundred thousand lines. Keeping the checks enabled for everyone from the beginning avoids accumulating that particular backlog. Fixing violations as code is written makes enforcement part of ordinary changes, rather than a large later migration.

Code quality matters for durable software and can cease to matter at the truly disposable end of the spectrum. Its cost is a separate engineering problem. Making rigor inexpensive to apply gives teams more room to change their minds about how durable a system needs to be—and gives a concrete answer beyond “it depends.”