What we will miss about the SDLC
Every transition in this industry gets narrated by its beneficiaries, which means the losses go unrecorded until it is too late to keep any of them. Some of what the old life cycle provided was genuinely good.
I have spent this series arguing that a life cycle built around human code production is being replaced by one built around specification, verification and proof, and that on balance this is an improvement. I still think that. But there is a habit in technology writing worth avoiding, which is describing a transition entirely from the perspective of what is gained and leaving the losses to be discovered later by the people who experience them.
Every previous shift did this. The move from mainframes to distributed systems was narrated as liberation and quietly gave up operational discipline that took twenty years to rebuild under new names. Agile was narrated as freedom from documentation and gave up a form of institutional memory that a great many organisations still do not have. In both cases the losses were real, they were foreseeable, and nobody wrote them down while there was still time to preserve anything.
So here is the accounting, written now rather than in five years.
Craft, and the fact that it was load-bearing
The most obvious loss is the hardest to argue for without sounding sentimental, so let me try to make it concrete.
A great deal of software quality came from people who cared about the code as an artefact. Not because caring was in the specification, and not because anyone measured it, but because they found it unpleasant to leave something worse than it could be. That disposition produced better naming, simpler structures, and the small refactor performed in passing that kept a module from calcifying.
None of it was ever in a requirement. It was a by-product of humans doing the work and having taste.
When work is generated against criteria, what gets produced is what the criteria demand. Criteria can express correctness, and with effort they can express performance and security properties. They cannot easily express “this is the elegant version.” A system optimised for passing criteria will produce code that passes criteria, and the difference between that and code someone was proud of is real even when it is not measurable.
Provided by craft, unpriced
- Naming that made intent obvious
- The refactor done in passing
- Structures that anticipated the next change
- Deleting what nobody needed
- Refusing to ship the ugly version
What criteria can express
- Correctness against stated conditions
- Performance thresholds
- Security properties, with effort
- Structural rules, crudely
- Not much else
I do not think this loss is total. Taste can move upstream, into criteria and reference implementations and the standard for what gets accepted. But that is a different mechanism, it requires deliberate effort, and it will be weaker than a hundred people each caring a little about the thing in front of them.
The apprenticeship
This is the loss I am most confident about and least able to offer a solution for.
Engineers learned by doing simple work under supervision. You were given the small bug, the straightforward endpoint, the test that needed writing. It took a day, someone reviewed it, and in the review you learned something. Repeat for two years and you had judgement, acquired through a thousand small encounters with the consequences of your own decisions.
The simple work is what automated first. Completely and immediately.
The pipeline problem gets stated often enough that it has become background noise, and it deserves more alarm than it gets. It is not merely that juniors have fewer opportunities. It is that the mechanism by which judgement was transmitted has been removed, and nobody has proposed a replacement that anyone has tested. You cannot acquire the intuition for what is likely to break by reading about it, and you cannot acquire it by reviewing generated code either, because review without the experience of having made those mistakes yourself is pattern-matching without a basis.
The organisations claiming to have solved this are, in the cases I have looked at, not hiring juniors. That is a solution to their problem and a contribution to the industry’s.
Knowing why the thing is the way it is
There is a kind of understanding that comes only from having built something, and it is different from having read it.
An engineer who wrote a subsystem knows which parts were hard, which decisions were forced by a constraint that has since disappeared, and which bits are load-bearing rather than incidental. That knowledge is not in the code. It exists because a person was present while the code came into being, and it is what makes them fast when something goes wrong at three in the morning.
Provenance chains are a genuine substitute for part of this. They record what changed, against what intent, verified how. That is more than the old world reliably captured, and I have argued elsewhere in this series that it beats memory in several respects.
What they cannot supply is the tacit part: the sense that this area is fragile, the recollection of the approach that was tried and abandoned, knowing which assumptions are load-bearing without being able to say why. That was always undocumented, and it is now also unformed, because nobody was there.
Slowness, which was sometimes doing work
This is the least intuitive item on the list and possibly the most important.
Building something slowly gave you time to change your mind. In the four weeks a feature took, the person who requested it often realised they wanted something different, or the market moved, or somebody noticed a problem with the premise. The delay was not merely cost. It was an option, held open, that occasionally saved an organisation from committing to a mistake.
Speed removes the option. A thing requested on Monday and shipped on Tuesday never passes through the window in which someone reconsiders. Most of the time this is pure gain. Occasionally it means an organisation has built and shipped something it would have talked itself out of, and shipped things are much harder to remove than planned things.
I am not arguing for artificial delay, which would be absurd. I am noting that a function was being served incidentally, and that organisations moving quickly need to serve it deliberately, most likely by becoming far more willing to delete than they have ever had to be.
The shared understanding that came from friction
Related, and easier to state. When six people had to coordinate to deliver something over a month, they ended up with a shared model of the system, acquired through the friction of coordinating. Meetings that felt wasteful were partly how context propagated.
Remove the coordination and the context stops propagating. The team gets faster and, over a year, gradually loses the ability to agree on what the system is. This surfaces as an increase in decisions that have to be escalated, because nobody holds a model complete enough to decide locally.
What is worth trying to keep
Not everything here can be preserved, and pretending otherwise would repeat the mistake this piece is complaining about. Three seem worth deliberate effort.
Taste, moved upstream. Someone has to own what good looks like in your codebase, express it in reference implementations and standards, and be willing to reject work that passes its criteria and is nonetheless bad. That role needs to exist explicitly, because it will not survive as a by-product.
Decision records, written at the time. The cheapest item on this list and the most neglected. A paragraph explaining why, written while the reason is still present in someone’s mind, substitutes for a surprising amount of what used to live in memory.
An apprenticeship path, invented rather than inherited. I do not know what this looks like. I am fairly sure it involves giving junior engineers real ownership of something small with real consequences, rather than having them review generated code, and I am confident that whoever works it out will have an advantage in five years that nobody is currently pricing.
Where this breaks down
Nostalgia is not evidence. Every generation of engineers believes the previous way had virtues that were lost, and they are usually partly wrong. Some of what I have called craft was self-indulgence, and some of the apprenticeship was exploitation dressed as training. Discount accordingly.
Several of these losses were already under way. Outsourcing, high turnover, service fragmentation and the general acceleration of the industry had been eroding craft, apprenticeship and shared context for a decade. Agents accelerate a trend rather than starting one, which matters for whether the diagnosis is right.
The gains are real and are not restated here. This piece is deliberately one-sided, because the other side is covered in the rest of the series and by the industry at large. Read it as a supplement, not a verdict.
I may be wrong about the apprenticeship. It is possible that a generation learning by directing and verifying rather than writing develops judgement by a route I cannot picture, in the way engineers who never wrote assembly still understand performance. I would not plan on it, and I would be glad to be wrong.
The takeaway
The transition is worth making and it has costs, and the costs are the kind that go unrecorded because they were never on anyone’s balance sheet. Craft, apprenticeship, the understanding that comes from having built something, the option value of slowness, and the shared context that came from friction.
Some can be preserved with deliberate effort. At least one, the apprenticeship, is an open problem that the industry is currently addressing by not hiring the people it affects.
If you take one thing from this series: the parts of your organisation that worked well without anyone designing them are the parts most at risk, precisely because nobody knows they are there. Find them before you automate around them.