Knowing When to Let My Creation Die

I Know Why Every Stitch Is There

Recommending that a business replace an application gets harder when my name is attached to its creation. I can explain the design decisions. I understand the constraints that shaped them. That knowledge is useful, but it can also make me very good at defending something whose best years are behind it.

Halloween gives that discomfort a familiar image: the creator standing beside an assembled creature, proud that it still moves. Another patch, another connection, another late adjustment to keep everything working together. There's a little Frankenstein in the temptation to treat continued life as proof that the experiment should continue.

An application can still run, still process transactions, and still produce the reports people depend on while becoming an increasingly expensive way to meet the business's needs. Its survival doesn't settle the question of whether it deserves the next investment.

The difficult part is admitting that my ability to keep it alive may have become less valuable than my willingness to help replace it.

The Features Remain. The Futures Have Reached Zero.

Kent Beck gives this condition a useful vocabulary in his 2026 talk, Features Versus Futures. Features provide functionality today; futures represent optionality, the capacity to change the software. Adding features consumes some of that optionality. Beck describes alternating feature work with investments that restore it, including better structure, tests, documentation, and delivery practices.

The state I'm describing is an application whose futures have effectively reached zero. That's my application of Beck's model to this retirement decision, a conceptual boundary rather than an empirical score. The current features may still have considerable value. But the next meaningful business change has no credible path through the existing design at a cost and risk the business can accept.

That explains why the application can look healthy to someone using it and exhausted to someone changing it. Today's work still gets done. Tomorrow's requirement triggers another round of exceptions, coupled changes, and uncertain regression testing. A successful demonstration of existing features tells me very little about the options left for the next release.

Zero futures doesn't automatically make a working application worthless or require immediate replacement. If the business needs it to keep doing the same job, continued operation may be entirely reasonable. The decision becomes urgent when the business needs to change and the application cannot follow without disproportionate effort.

The creator's attachment is especially dangerous here. I can point to everything the application does as evidence for preserving it, while the business is trying to decide what it needs to do next. The creature still moves. That doesn't establish that it can grow.

Evolution Has an Exit Condition

In Evolution over Revolution, I argued for improving what exists before reaching for a rewrite. Existing software contains knowledge that a clean architecture diagram rarely captures. Small changes can deliver value sooner, expose assumptions earlier, and leave the business with something useful even if the larger effort stops.

I still stand behind that argument. It also needs a boundary.

Evolution works while the application offers a reasonable path toward the quality the business needs. That includes dependable behavior, safe changes, understandable operations, and the ability to accommodate new requirements. When the underlying structure repeatedly prevents those outcomes, another local improvement may only postpone the same decision.

The distinction matters because old code isn't evidence that replacement is necessary. Neither is an unfashionable framework or my frustration with a difficult module. A system can look dated and serve the business very well. What concerns me is persistent friction: ordinary changes crossing unrelated parts of the application, fixes reopening defects elsewhere, and testing becoming harder despite deliberate efforts to improve it.

Restoring futures is the reason to invest in evolution. If isolating a component, improving tests, or simplifying a model makes the next changes affordable again, that investment has a purpose beyond keeping old code around. The exit condition arrives when a replacement offers a more credible, affordable path to the changes the business needs, after accounting for transition costs and risk. Evolution over revolution is a preference grounded in consequences. It can't become a promise to preserve an application forever.

The Time Already Spent Is Gone

The sunk cost fallacy enters when the reason to continue becomes the effort already invested. Years of development, difficult releases, and the money spent getting here can make replacement feel like admitting that the entire undertaking was a mistake.

That conclusion doesn't follow. The application may have paid for itself many times over. It may have helped the business discover a market, understand a process, or grow beyond the assumptions that made the original design sensible. Reaching the end of its useful life doesn't erase that value.

The money already spent cannot be recovered by choosing another maintenance release. The decision concerns what happens next: the expected cost, benefit, and risk of continuing compared with the available alternatives.

Maintenance friction belongs in that comparison because it is a future cost. So do migration, training, lost delivery time, and the possibility that a replacement takes longer than expected. Existing capabilities also have present value. Ignoring past expenditure doesn't mean pretending the working application contributes nothing.

My attachment makes this harder. If I designed the application, a discussion about its limitations can feel like a judgment on my competence. I can start explaining why a decision was reasonable when the business needs to know whether it remains reasonable. Both questions deserve answers, but only one determines the next investment.

AI Moved the Crossover Point

For most of my career, the default assumption was that keeping a working application was cheaper than rebuilding it. Replacement meant spending a great deal of money just to recover capabilities the business already had. Even a poorly designed system carried protective value, because reproducing what it did was so expensive.

AI-assisted development is changing that arithmetic. Producing new code from a clean architecture and a well-understood business problem costs noticeably less than it did a few years ago. The gains I see are uneven. They are strongest on new, well-bounded work and weakest inside a large, tangled codebase, which is exactly the place where an aging application lives.

That suggests an extension of Beck's model I keep returning to. What happens when creating a new future costs less than preserving the old one? The question shifts from "can this still be maintained?" to "where does the next dollar create the most business capability?"

That doesn't make every rebuild faster than incremental work. What changes is when replacement becomes a credible alternative. A rewrite that once required eighteen months of a large team, and lost easily to a six-month modernization, might now be worth putting in front of the business much earlier in the application's life. Its useful economic life gets shorter because the cost of replacing it has fallen, even though the application itself has decayed no faster.

The trap is confusing the cost of rebuilding code with the cost of replacing a business system. Data migration, integrations, security reviews, compliance, operational support, undocumented business rules, and the people who have to learn a new way of working don't get cheaper because code generation did. A team can produce far more code with AI and still ship only modestly more working software. The comparison has to be made in delivered capability.

It also adds an option I tend to skip past. Faced with maintain, modernize, or replace, I rarely ask whether the capability is still needed at all. Retiring an application without replacing it is sometimes the cheapest future available, and a cheaper rebuild makes it easy to forget to ask.

The Lessons Can Outlive the Code

Starting again with what the business now understands is a different proposition from starting with what it knew the first time.

The original development helped reveal which requirements mattered, which workflows people actually used, and which exceptions were central to the business. Some requested features may never have earned their maintenance cost. Other capabilities may have become far more important than anyone expected. A replacement can be designed around that understanding.

The opportunity is to carry the learning forward without automatically carrying every implementation decision with it. That requires making the learning visible. Business rules, examples of expected behavior, operational requirements, and migration constraints need to be understandable outside the old codebase.

Otherwise, the supposed fresh start is partly an exercise in forgetting. A developer removes an awkward exception because its purpose isn't obvious, and the business later discovers that it supported an infrequent but necessary transaction. The cleaner implementation has reproduced less of the actual requirement.

I want the replacement to benefit from the years already spent. That means extracting their value before retiring their machinery. Some code may survive as a library, a test, or a useful integration. Some may have nothing left to contribute beyond explaining a decision the next application should avoid.

Cheaper rebuilds raise the stakes on this. If the code can be regenerated, then the durable assets are the things AI can't recover on its own: validated business rules, real workflows, integration contracts, portable data, and acceptance tests the business can read and run. The source code becomes one implementation of those assets, and an increasingly replaceable one. That reframes Beck's futures for me. Preserving the business's capacity to change sometimes means refactoring the codebase and sometimes means replacing it altogether.

Technical debt gains a second dimension as well. I used to describe it as the extra cost of changing the existing implementation. It now also includes the opportunity cost of keeping an implementation when a replacement could give the business more flexibility for less total cost. An aging codebase can have no defensible economic future while the capability it supports remains extremely valuable. The future belongs to the business capability, not necessarily to the application implementing it.

Comparing the Next Few Years Honestly

For the kind of application discussed here, I would put the same business requirement beside each option. Take a change to an approval process: an additional approval level, a new delegation rule, and an audit record that operations can explain without calling a developer. This is an illustrative comparison, not a report from a client project.

Continuing with the existing application might require changes across screens, background processing, and reporting because each holds a different version of the approval logic. Selective replacement might isolate that logic and leave the rest of the application operating. A fresh application might express the process coherently, but it would also need the current permissions, historical records, integrations, and operational support before it could take over.

The comparison becomes useful when those dependencies are visible. I would want estimates expressed as ranges, with the assumptions behind them, over the same period and for the same required outcomes. The replacement estimate needs to include running both systems during transition and maintaining the old one until the new one earns trust. The maintenance estimate needs to include the work repeatedly deferred because changes are too risky or expensive.

A three-year horizon works as a first screen. On the keep side: maintenance and support, the enhancements the business actually plans, the debt remediation those enhancements will force, and a monetized estimate of the risk of staying. On the replace side: the build, migration and integration, testing, transition, and training, the new system's operating cost, and its own risk.

AI mostly shrinks one line on the replace side, the build. If the comparison flips, I want to know whether it flipped because of that line or because someone quietly underestimated the others. It's a screening model, not a business case, and both sides have to deliver comparable capabilities and service levels for the numbers to mean anything.

I would also want evidence that the new design removes the specific obstacle. A small implementation of the difficult approval behavior can test whether a different model actually makes change safer. With AI, a convincing prototype is cheap, so I'd ask for a vertical slice instead: a representative workflow running through real integrations, tests, security, and deployment.

Then I would change the delegation rule again. How much has to move, and can the tests establish that the existing approval paths still work? That second change provides evidence of futures being restored. If the same complexity reappears, perhaps it belongs to the business process rather than the architecture. A new codebase won't make that complexity disappear.

There may be no affordable replacement this year. Funding, staff, and the business's tolerance for disruption constrain the choice. A bounded maintenance plan can still be sensible, provided the business understands what it buys and what it postpones. The choice to wait deserves the same honesty as the choice to rebuild.

A Fresh Start Needs a Different Habit

A replacement can arrive at the same exhausted state if the development habits that consumed its predecessor's flexibility remain unchanged. A faster route to the first release doesn't establish a longer useful life.

AI makes that concern more immediate for me. Generating the next feature quickly is attractive, but speed alone gives me no assurance that the resulting code will be easier to change. I can approve a succession of working additions while overlooking the growing effort needed to understand how they interact.

There's a second temptation hiding in the cheaper rebuild. If replacing an application gets easy, a team can start rebuilding every time a system gets hard to change, and never learn how to keep one changeable. AI will happily reproduce the same architectural mistakes at greater speed. A disposable application isn't a strategy if the reason it keeps getting disposed of never changes.

My translation into DevSpark practice is to build a small, valuable increment, verify its behavior, tidy the structure, and repeat. Verification includes existing behavior. Tidying addresses the coupling, duplication, or unnecessary complexity that would make the next increment harder. I want to carry that habit into a replacement alongside the lessons learned about the business.

The case for starting again gets stronger when I can explain both what the new design changes and how I intend to preserve its capacity for further change. Otherwise, I may simply be asking the business to fund a younger version of the same creature.

The Business Still Has a Choice

My responsibility is to make those options understandable. I can recommend continued maintenance, replacing a difficult part, buying an existing product, building again, or retiring the capability entirely. I also need to explain what would change my recommendation and where the estimates remain uncertain.

The business owns the decision because it carries the consequences. My affection for the application doesn't give me authority to conceal an option. Neither does my enthusiasm for a new project give me permission to make the replacement look easier than it is.

Staying Responsible Through the Ending

The Halloween metaphor has a limit. Letting an application die doesn't mean walking away from the people who rely on it. Retirement needs an owner, a transition plan, accessible records, and a clear account of which responsibilities move to the replacement. Until that happens, the old application still has a job.

I would want the conditions for turning it off agreed before the replacement becomes another indefinite project: which business processes must work, how migrated records will be checked, who accepts the result, and what happens if the transition fails. Building the replacement and ending the dependency on the original are both part of the work.

I can be proud of something I built and still recommend its retirement. In fact, understanding it well may make me the person best placed to explain why the time has come. That requires staying involved long enough to help the business move on, even when moving on means no longer needing my creation.

I know why every stitch is there. I owe the business an honest answer about whether another one is worth making.

Explore More

• Evolution over Revolution: A Pragmatic Approach — why incremental improvement is often the right starting point, and why it needs an exit condition.
• Momentum Is Not Propulsion — how continued activity can outlast the business reason for doing it.
• Solve the Problem, and Get Out of the Way — building applications the business can operate without making the developer a permanent dependency.