There was a time when technology decisions routinely included a discussion of Total Cost of Ownership (TCO).
We understood that the purchase price was only the beginning. Hardware had to be installed, powered, cooled, maintained, upgraded, and eventually replaced. Software had to be configured, integrated, secured, supported, documented, and taught to the people expected to use it. Someone had to respond when it failed, and someone had to understand it well enough to change it without breaking everything around it.
The cheapest option to acquire was not necessarily the least expensive option to own.
Whatever happened to that idea?
Today, particularly in discussions of AI-assisted software development, we seem preoccupied with the cost of creation. How quickly can we build it? How much code can an agent generate? How many developers can we avoid hiring? How soon can we put something in front of customers?
These are not meaningless questions. Implementation cost matters.
But it is only one part of the bill.
Terry Pratchett illustrated the problem with a pair of boots. In Samuel Vimes’ Boots Theory, a person with enough money can buy a good pair that lasts for years. A person without enough money buys the inexpensive boots available today. Those boots wear out quickly, so they must buy another pair, and then another. Over time, the person who could least afford the expense pays more and still has wet feet.
Boots Theory is not really about footwear. It is about false economy: accepting a lower immediate cost while creating a greater cost over time.
I once inherited a software project that had gone to the lowest bidder. There was no meaningful documentation. Components were splattered across the filesystem, with little indication of how they fit together. Before I could begin fixing the system, I first had to guess what it had been written in. The answer turned out to involve several languages and frameworks.
Much of the cost saved during acquisition had simply been transferred to whoever came next.
I reconstructed enough of the system to maintain it, but I never did fully identify the race condition buried inside it. The implementation had been purchased cheaply.
The uncertainty came with it for free.
Software organizations buy cheap boots constantly. We will document it later. We do not need tests yet. We will clean it up after launch. We can hard-code that for now. It is only a prototype. We can always rewrite it.
Each decision may produce a genuine short-term gain. Sometimes a shortcut is the right choice. The mistake is pretending that the gain eliminated the cost.
It usually moved it.
Deferred cost is not avoided cost.
AI Makes the First Pair of Boots Cheaper
AI makes creating software faster and less expensive. That is real, useful, and potentially transformative. It can make ideas testable that would previously have been too expensive to explore.
What it does not automatically lower is the cost of ownership.
Someone still has to determine whether the software solves the right problem, understand its assumptions, validate its behavior, operate it, support it, change it, and eventually retire it. Someone still has to explain what it does when the person who prompted it no longer remembers—or no longer works there.
AI can make the first pair of boots almost free. It does not guarantee that the boots fit, survive the weather, or can be repaired. Nor does it remove the need to walk in them for the next five years.
This is why AI makes Total Cost of Ownership more important, not less.
When implementation was expensive, its cost imposed a crude form of restraint. Features had to compete for developer time. Experiments had to justify their budgets. Someone could object that an idea would require three months of work.
That friction was often frustrating, but it forced prioritization.
Now the response may be, “The agent can build that this afternoon.”
The disappearance of implementation friction does not make every feature worthwhile. It merely removes one of the forces that once encouraged us to ask.
The cost of a feature is not what it takes to generate.
It is what it takes to own.
The Warp Comes Before the Cloth
Hand-weaving provides another way to understand the problem. A large portion of the work happens before the visible weaving begins. The weaver selects the fibers, calculates the dimensions, measures the warp, threads the heddles, dresses the loom, and establishes the tension.
To someone watching from outside, this preparation may look like delay. No cloth is appearing. Nothing seems to be getting made.
But the warp determines what can be woven.
Once the loom has been prepared properly, the visible production may proceed quickly. If the warp is wrong, weaving faster only produces more flawed cloth.
Software has a warp too. It includes understanding the problem, identifying constraints, defining boundaries, exposing assumptions, making architectural decisions, and deciding what success and failure mean.
AI can move the shuttle astonishingly fast.
That makes preparing the warp more important.
A vague intention can now become thousands of lines of interconnected code before the organization has fully understood what it asked for. A poor assumption can propagate through an entire system in the time it once took to write a single module.
Think before you generate. Think again before you commit—not because generation is expensive, but because consequences are.
Living With What We Build
Years ago, I began thinking in terms of maintenance-driven development. Software development methods often emphasize how software comes into existence: requirements, tests, behaviors, features, delivery, or deployment.
But creation occupies only the beginning of a successful system’s life.
For most of its existence, software is being used, operated, investigated, repaired, adapted, secured, extended, and explained. Even adding a new feature usually requires understanding and changing what is already there.
Maintenance-driven development does not mean opposing features. Software without useful capabilities has little reason to exist. It means delivering value in a way that respects the future.
Naming, documentation, tests, observability, clear boundaries, and deliberate architecture are not ornamental work added after the “real” development is complete. They help determine whether an organization can continue receiving value from what it built.
Total Cost of Ownership asks:
What will this system cost across its lifetime?
Maintenance-driven development asks:
How should we build it, knowing that someone will have to live with it?
But those questions contain an often-unspoken assumption:
Who owns it?
Not necessarily one person with one neck to wring. Complex systems require shared responsibility. Product, engineering, operations, security, support, finance, and leadership may each own different decisions and consequences.
Shared ownership, however, is not the same as ambiguous ownership.
When no one accepts stewardship of a system, its costs do not disappear. They diffuse. Operations absorbs one cost. Support absorbs another. Security inherits the vulnerabilities. Finance receives the infrastructure bill. Customers encounter the defects. Future developers reconstruct the missing knowledge.
The organization owns all the consequences while no one owns the decisions that produced them.
An unowned system becomes everyone’s problem and no one’s responsibility.
AI makes creating more systems easier. Unless we are careful, it may also increase the number of systems that no one truly understands or owns.
Accountability is therefore part of Total Cost of Ownership. Someone must have both the responsibility and the authority to ask whether a feature remains worth supporting, whether a dependency is still justified, whether a shortcut should now be repaired, and whether the system should continue to exist at all.
Responsibility without authority creates scapegoats.
Authority without responsibility creates negligence.
Stewardship requires both.
It also requires the courage to say no.
The Discipline of Not Building
YAGNI—You Aren’t Gonna Need It—is sometimes treated as an argument against foresight or design. It is better understood as a warning against unnecessary commitments.
Every feature creates behavior that must be understood. Every option creates combinations that must be tested. Every integration creates another relationship that can fail. Every dependency creates another source of change outside our control.
Every “yes” creates something the organization may have to own for years.
AI makes saying yes easier. Stewardship makes saying no more important.
The easiest feature to maintain is the one never built. But restraint does not mean rejecting every idea. It means requiring an idea to justify not only its creation, but its continued existence.
A mature system is not one to which nothing else could possibly be added. It is one to which nothing else should be added without accepting the consequences.
Builders ask:
What can we make?
Stewards also ask:
What should we choose to own?
Engineering Is Stewardship
Total Cost of Ownership is not merely an accounting exercise.
It is a way of seeing.
It asks us to look beyond acquisition, implementation, and launch. It asks us to notice the obligations created by our decisions and the people who will inherit them.
A schema creates future migrations. An API creates compatibility obligations. A feature creates customer expectations. A dependency exposes us to another organization’s decisions. A shortcut creates future investigation. A system creates the need for understanding.
Every solution is a commitment.
This is why engineering is not merely the act of building things.
Engineering is the stewardship of consequences over time.
The implementation matters. The feature matters. The value delivered today matters. But engineering also asks whether that value can be preserved, whether the system can be understood, whether its obligations are sustainable, and whether the organization is prepared to own what it has created.
AI may make software astonishingly cheap to produce.
It does not make consequences free.
The next time someone says, “The agent can build that this afternoon,” perhaps the question should not be whether we can afford to create it.
The question should be:
Are we willing to own it?
No responses yet