Code Quality Has a Simple Answer: It Depends on Disposability

The framework. Max Kanat-Alexander, a Capital One engineer, argues that all software success depends on two factors: understanding the system and executing on that understanding. Code quality practices exist only to serve these two goals. On small systems, understanding is trivial. On real systems like Chromium, with millions of interacting components, structure becomes essential for comprehension and safe modification.

The risk model. Every modification carries two categories of risk: introducing a problem (bugs, budget overruns, timeline slips) and making future changes harder. Both stem from failures of understanding. Poor structure compounds these risks non-linearly over time, eventually making every change painful. This is why large legacy systems become unmodifiable.

The new category. Kanat-Alexander introduces disposable software: systems with minimal consequences of failure, few dependencies, near-zero replacement cost, and negligible maintenance cost. In this world, code quality does not matter. AI coding tools make disposable software dramatically more common. Think of a party planner written for a single event, then thrown away.

The spectrum. Disposable and durable are not binary. The same four factors — consequences, cost of replacement, dependencies, and cost of maintenance — determine where a system falls. The speaker warns that engineers should err on the side of durability. But organizations can also actively increase disposability through isolated environments, enforced independence, and redundancy.

Reducing rigor cost. The most important engineering work is not increasing rigor, but decreasing the cost of rigor. Standardization removes entire categories of tooling and knowledge. Inward-flow tooling that runs automatically, reliably, and fast makes rigor feel free. Making testing easy through in-memory fakes and fast, deterministic infrastructure reduces friction.

The bottom line. The question "Does code quality matter?" has a concrete answer: no for disposable software, yes for durable software. The more interesting question is whether rigor must be expensive. It does not. Teams should invest in making rigor cheap enough to apply everywhere, including systems they initially assume are disposable.