Unattended
A quiet channel after delivery sounds like success. It sounds exactly the same as abandonment.
Somewhere in a cloud tenant, a job wakes on a schedule. It opens a mailbox, collects the documents it finds, and pushes each one through a paid extraction service. Partway down the pile it reaches a file larger than it can handle, and dies. It never recorded how far it had come, so the next run starts at the beginning: the same documents, the same paid service, the same collapse at the same file. It does this every few minutes, day and night, for weeks. Every attempt is billed.
Attention in a software project is front-loaded. At the start everyone is present and everyone is enthusiastic, and the enthusiasm is not naive. What people picture when they ask for automation is specific: the three hours spent reading numbers out of a document and typing them into a screen, work that asks for no judgement and leaves the person doing it feeling meaningless. The first thing they name is usually cost, but the thing they actually want is room – hours moved off work that merely keeps the business upright and onto work that grows it. That instinct is right, and it is worth building for.
The people who build it feel much the same. The first weeks are the best part of the work, and they have got better: what took months takes days, and far fewer developers are needed to carry it. Nothing of that kind exists once the system is live. A build has a beginning everyone turns up for and an afterwards nobody has planned.
The handover looks like completion. The system is deployed, the manual is written, two pieces of feedback come back and are fixed, and then the communication stops. From the outside this is indistinguishable from success. A quiet channel after delivery is what a finished project sounds like.
It is also what an abandoned one sounds like, and nothing in the silence tells the two apart.
At some point after go-live the people it was built for stop opening it. Why is rarely obvious, and it stays unobvious, because the question is never put to them. Automation is not a point, it is a chain. A process runs through several pairs of hands, and the automation of the whole is only as real as its weakest link. The gains along that chain are rarely even: whoever benefits most tends to sit downstream, and depends on everyone ahead of them having done their part inside the system. When one link stops, the ones behind it have nothing to work with, and the process reverts to what it was for everybody. Nobody decides this. The chain simply has a gap in it, and a chain with a gap is not a slower chain, it is not a chain.
That is the part worth sitting with: the two failures hide each other. Nobody is using the system, so nobody notices it burning money. Nobody is watching the money, so nobody notices it is unused. Two silences, each supplying the other's cover. What finally breaks it is the invoice – the slowest sensor available, and the only one anyone has left running.
Logs exist the whole time. Every crash is recorded in detail. Logging is memory, though, and memory answers questions nobody thought to ask. Alerting is attention, and no attention is being spent. The same goes for the spending ceiling nobody sets, on the sound theory that infrastructure for this kind of workload is cheap – which it is, right up until failure becomes the workload.
Where more than one company is involved, this is where the seams show. A system built by one party, deployed into a second party's environment, used by a third. The environment belongs to one of them, the code to another, and the alert that should fire belongs to whoever agreed to own it – a conversation that either happens at handover or does not happen at all.
The front of a project is where everyone wants to be. Scope, potential, the next phase, what else could be automated – those are easy conversations to get people into, and they are genuinely enjoyable. What sits behind them is another kind of work: keeping a relationship warm when there is nothing to sell, asking a question nobody requested. Fewer people want that half, and it takes no negligence for the gap to open. A great many projects are simply shaped this way: a start, an end, a closing budget, a final invoice, and both sides turning to the next thing. With several parties the gap widens, because whoever holds the relationship with the customer is often not the one who can read a log, and whoever is reading the log is not the one in contact. If the relationship is not kept alive by the party holding it, everything behind it stalls: the next phase goes undiscussed, small problems go unreported, and the system keeps running unwatched. Nobody declines responsibility for the period after delivery. It is never assigned, and unassigned responsibility is indistinguishable from responsibility being handled. It takes an event to tell them apart, and by the time the event arrives it has already cost something.
The ground moves as well. A solution fits the process as it was described during specification, and the process keeps changing afterwards – steps get added, a system upstream changes hands, someone leaves. It does not take a changed process, though. A solution can be genuinely faster than what it replaced and be dropped anyway, because one control everyone needs sits two clicks deeper than anyone will go. Whoever hits that on the first day notices it, means to mention it, and then the day fills up. So does the next one. By the second month the intention is gone and the old habit is back, without anyone having chosen it.
Nothing in the source code changes. The value leaves anyway. Custom software is worth what it is used for and nothing besides, and that worth moves week by week.
The word for this is maintenance, and it is a poor word. It suggests keeping a thing as it was, which is rarely an option. What it actually means is keeping a system in contact with a process that will not hold still: noticing when the fit slips, and closing the distance before anyone quietly stops. Maintenance is not the tail end of a project. It is where the value built during it is either kept or lost.
Which is why contact after delivery is a necessity rather than a courtesy, and why its timing matters more than its tone. Asked in the second week how it is going, people say it's great, and mean it, and are still not using it. Asked in the third week with something specific – usage is lower than expected – the answer gets substance. Something came up that the system did not cover, the old way was quicker that morning, and the habit never came back. Something stopped working and got buried under everything else that had to be done that day. Each of those is worth a call to find out. Without the call none of them arrive, because the person holding the answer does not know they are holding one.
The machine, for its part, keeps its side of the agreement. It runs exactly as instructed, on schedule, without complaint, into an empty room, for weeks, and charges for every attempt.
What is missing is never expensive. A ceiling, an alert, a name written next to the question of who is watching, a standing call every week or two. All of it small next to the build, and smaller still next to the invoice. Software that is looked at keeps the worth it was built to have. Delivery ends a project. It does not end a system – it should start one.