Max Kanat-Alexander: do we need quality in code that can be replaced? (#AI4SDLC)
Max Kanat-Alexander from Capital One has given a talk, “Does Code Quality Still Matter?”, that follows naturally from the theme of my DotNext keynote: what happens to engineering when it becomes easier to generate an implementation again than to maintain it for years?
Max starts with why we need code quality at all: to understand the system’s actual behavior and change it safely. Every change can break something now and make subsequent changes harder. In the latter case, difficulties with understanding start accumulating.
He then proposes a spectrum from disposable to durable software. At one end is a program for organizing a single party. At the other is a system that people and businesses depend on for years. Four things determine its position: the consequences of failure, replacement cost, dependencies, and maintenance cost. In the first case, Max argues, code quality may not matter. In the second, engineering discipline remains necessary.
Replaceability can also be increased deliberately: isolate the environment, limit dependencies and scope, and keep a reliable fallback. The cost of discipline itself can be reduced through shared standards, automated checks, and convenient testing infrastructure.
This is where I would distinguish the lifetime of a system from the lifetime of its implementation.
At DotNext I developed ideas from Chad Fowler’s book “Regenerative Software”. A system can live for decades while individual components’ code is regularly replaced. For that to work, accumulated knowledge must survive the next generation of code:
— intent and invariants: what the system promises and what must not be violated; — architectural boundaries and contracts: exactly what can be replaced independently; — behavioral checks: how to establish that a new version fulfills those promises; — the reasons behind decisions: why retries are limited here, an odd check was retained, or this particular order of operations was chosen.
To me, this is an important part of regenerative software development. We deliberately create conditions in which an implementation can be discarded while preserving the system’s behavior and our understanding of it. A folder of Markdown alone does not give us that ability :)
Cheap generation does not yet mean cheap, safe replacement. You can rewrite a payment component in an evening, but that does not remove requirements around rounding, repeated requests, and compatibility. Being able to obtain different code quickly addresses only part of the problem.
In a mature system, we first have to extract what only the old implementation knows: implicit business rules, traces of incidents, and neighboring components’ dependencies. Then we must protect that knowledge with checks, replace components in stages, and retain the ability to roll back. While knowledge lives only in code, deleting the code destroys some of the knowledge too.
That is why I see a direct connection between Max’s point about making engineering discipline cheaper and my own talk. Shared checks and infrastructure reduce the cost of each subsequent replacement. And architectural quality can be tested very concretely: which component can we recreate today, and how will we prove that the system has retained the behavior we need?
#AI4SDLC #Engineering #Architecture #Software #AI #Conference