The Future of Software Engineering Has a Surprisingly Familiar Past

A recent LinkedIn post from my old friend George Jeffcock triggered one of those moments of recognition. He was describing where AI-assisted software engineering appears to be heading, but parts of it sounded surprisingly familiar.

For those of us who were building software in the 1990s, there was a time when considerably more effort often went into understanding and describing a system before implementing it. That wasn’t confined to model-driven development or CASE tools. The same was broadly true across conventional 3GL and 4GL development.

This wasn’t because we had discovered the perfect way to engineer software. Nor was everything waterfall. We iterated, prototyped and changed our minds. But iteration was often at a larger scale, with more emphasis on understanding the shape of the system before committing to its implementation.

There was a good economic reason for that: implementation was expensive.

Writing, testing and changing software consumed substantial human effort. Getting further into implementation before discovering that we had misunderstood the problem could be very costly. Analysis, specification and design therefore had considerable economic value until the economics changed.

Frameworks removed work we previously had to do ourselves. SaaS platforms gave us large amounts of capability out of the box. Low-code tools made some kinds of development dramatically faster. Agile practices shortened feedback loops and encouraged us to learn by putting working software in front of people.

Building something in order to discover what we really needed became increasingly rational, and much of that was progress in advancing business outcomes. There is nothing inherently virtuous about spending months specifying the wrong thing when you could discover the right thing by building a small part of it.

But it's only now in this time of disruption that the consequences of that rapid iteration surfaces. What we learned through implementation wasn’t always consolidated back into an authoritative description of what the system was intended to do, and so decisions accumulated in code, configuration, workflows, data models and integrations. Documentation and specifications didn’t disappear, and plenty of teams retained strong design disciplines, but their relative authority changed.

Eventually, for many long-lived systems, the most reliable answer to “What does this actually do?” became: look at the implementation. And so here is the consequence of the speed and agility of all those changes.

We made software cheaper to build, but not necessarily cheaper to understand.

Now AI is changing the economics again, because if the cost and effort required to turn an idea into working software continue to fall, then the relative value of precisely understanding what we want to build rises. Practices that made less economic sense when implementation itself was the dominant cost may deserve another look. That doesn’t mean returning to the software engineering methods of thirty years ago. The more valuable possibility is that authoritative specifications could become important again for entirely new reasons.

There is, however, an immediate problem.

Most enterprises aren’t starting from scratch. They already depend on systems containing years, sometimes decades, of accumulated decisions, and in many of those systems, the implementation has effectively become the specification.

So before we can make specifications authoritative again, we face a harder question:

How do we recover a clear specification when the software itself has become the only reliable description of how the business actually works?