Software has a life after the demo

There is something genuinely exciting about describing a piece of software and watching a working version appear. A process that once required a queue, a budget and several meetings can sometimes begin with a conversation.

The next question arrives rather less theatrically: who is responsible for it on Tuesday?

By Tuesday, someone has entered an unexpected value. A permission has changed. The application needs to connect to a system that was not part of the demonstration. A colleague would like to know whether the numbers are correct, ideally before sending them to the board.

Generated software makes this question more important because it lowers the cost of creating the first version. More people can build more things. That is useful, provided the operating life of those things has somewhere to go.

A business application acquires obligations as soon as people rely on it. It must keep appropriate records, preserve access boundaries, recover from failures and respond sensibly when the surrounding systems change. Some tools will be temporary and low-risk. Others will quietly become essential because the spreadsheet they replaced has already been deleted.

These obligations are well established. The NIST Secure Software Development Framework treats security as something incorporated into the development lifecycle, including responding to vulnerabilities. Generating code changes how code is produced. It does not settle who will identify a vulnerable dependency or decide when a fix is safe to release.

Hosting resolves part of the problem, but the word can conceal a surprising amount. A running server is useful. A reliable business service also needs an understood division of responsibility. The AWS shared responsibility model makes this explicit: the customer's responsibilities vary with the services used and can include application software, configuration and access controls.

A generated application hosted on a capable platform may inherit substantial protections. It can still make a perfectly well-hosted mistake. The distinction is easy to appreciate when the mistake concerns someone else's system and rather more urgent when it concerns payroll.

Integration adds another layer. A business process rarely ends at the edge of the screen. It reads from somewhere, writes somewhere else and relies on definitions that people may disagree about. What counts as an active customer? Which system owns the address? What should happen if the update succeeds in one place and fails in another?

These are product and operational questions. Better code generation may help implement the answers, but somebody still needs to establish them.

Then comes observation. If the application stops doing the right thing, how will anyone know? Google's Site Reliability Engineering chapter on monitoring discusses the need to understand a service's behaviour and detect conditions requiring action. A dashboard that reports the server is alive offers limited comfort if yesterday's orders have been processed twice.

For a modest internal tool, the answer need not be a large operations department. It may be a named owner, a few meaningful checks, a recovery procedure and a clear route for making changes. The effort should fit the consequence of failure. A lunch rota and a payment workflow deserve different levels of ceremony.

What interests me is the opportunity this creates. As the first version becomes easier, more of the value may move into making software usable over time: connecting it properly, hosting it responsibly, maintaining it and keeping its behaviour understandable to the people who depend on it.

That work may be delivered by a platform, a specialist team or the organisation itself. Much of it can also be automated. The important point is that it remains part of the service, with a cost and an owner, even if it becomes less visible.

There is a useful test for any new application. Imagine the person who created it goes on holiday. Can someone else understand what it does, see when it fails and restore it without recreating the original conversation? If the answer is yes, the software has begun to grow beyond its demonstration.

The promise of generated software is substantial. We should be able to build useful tools more quickly and make more ideas worth trying. Giving those tools a sensible operating life is how that promise reaches the people who will actually use them.