Among the things that would most surprise a younger engineer reading about software in the 1990s is how the work itself was organised. The methods now treated as the natural way to build software did not exist, and the practice that preceded them deserves an honest description, neither as a lost golden age nor as a primitive era the industry was right to leave behind.
How the work was organised
User requirements were drawn up once, at the start of a project, and were not revised every few weeks. There was no Jira, no sprint, no daily stand-up, no continuous integration pipeline. Each engineer was given a block of work, owned it for months, and the pieces were joined together near the end. Code review as a daily gating condition for merging did not exist. You showed your code to a colleague when you wanted a second opinion, not as a requirement for it to ship.
Where it failed, and why the correction came
We will not pretend that was a better way to work. Most of what later practice introduced was a response to genuine failures of the older approach, and the failures were real. Projects ran long. Requirements drifted away from what the business actually needed. Integration at the end of a six-month build revealed assumptions that no two engineers had ever agreed on, surfacing late and at cost. Agile practice, continuous integration, and short feedback loops exist for a reason: the older approach broke often enough that the industry stopped tolerating it. That correction was earned, and it was the right one.
The depth worth recovering
What the older approach offered, and what is underappreciated now, was a particular kind of depth. Owning a block of work for three or four months without interruption let an engineer learn a problem domain in a way fortnightly context-switching does not. You read an entire vendor specification, the FIX dialect of a routing platform such as Fidessa for instance, since nothing would summarise it for you. You understood a system’s behaviour under load, since you had watched it for long enough. Breadth and responsiveness in modern practice are genuine advances. Depth in the older practice was also genuine, and the two are not opposites.
The most effective engineers we have worked with since have found ways to recover some of that depth inside the modern structure rather than treating the choice as settled. They protect stretches of uninterrupted attention. They read the whole specification rather than the summary. They build a mental model of a system thorough enough to predict how it fails, not only how it behaves. Modern practice makes that depth optional in a way the older practice never did, and the engineers who choose it anyway are the ones whose work we trust most. Changing the shape of the working week was the right move. The value of understanding a problem completely did not change with it.