 |
The reason for the detour is gone, |
Our new CTO does not believe in Technical Debt.
If you are not familiar with the concept, Technical Debt is a metaphor first proposed by Wade Cunningham in the early 1990s. In an Experience Report for OOPSLA 1992 (the annual conference for Object-Oriented Programming, Systems, Languages & Applications), he wrote:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. ... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
As a manager of teams responsible for maintaining apps built upon legacy code, I see the impacts of that technical debt on a regular basis. Some business logic got buried in the wrong place in the code, for reasons of expediency or carelessness, and now reusing that code takes a monumental effort.
 |
| Technical Debt |
So why does our CTO not believe in the concept? Why does he not subscribe to this common metaphor in our industry? The short answer is: perspective.
He views the state of the code base from the perspective of the company, the evolution of the suite of products over time, rather than from the perspective of the technical players, the devs and engineers who see it as an accumulating weight slowing them down.
Technical Debt, from this perspective, is about changes to business requirements over time. Why were shortcuts taken? To ship faster, thereby getting an app or feature set to production by a deadline for business reasons. Why are we struggling to make changes now? Because the business requirements have changed; had they remained static, any "interest payments" in the metaphor would have been manageable, or at least acceptable to the company.
The irony is that our CTO was unconcerned about the accumulated Technical Debt until Artificial Intelligence came along.
When our applications evolved through the sweat and toil of humans, the interest payments in the tech debt metaphor were acceptable to pay, and were explained to my team and to senior leadership as the necessary price of delivering on the new business requirements.
AI radically changed the calculations behind these Technical Debt payments. Now, a massive refactoring that would have taken the team days can be done in hours; estimates of weeks can now be reduced to mere days.
It is as if AI walked into the room carrying a chest full of gold coins. Now those tech debt payments were affordable, using that AI gold.
Yet now, even with the AI-powered development and the reduced impact of Technical Debt, our CTO has approved projects to clean up the code base. We have initiatives either scheduled or already under way to refactor some corners of the codebase or to rip out others that have minimal traffic or too few customers.
Why the interest in repaying that Technical Debt now? It is because of the rising cost, not of the Tech Debt in our metaphor, but the rising cost of tokens and AI usage. The massive codebase needs AI tools that can handle a large context; those tools then need to work through millions of lines of code across several distributed systems and micro-services.
That all costs real money. Not in terms of hours needed for a human to deliver new features despite the sub-optimal code; rather in dollars needed for the AI tool to work its magic.
AI might bring its own metaphorical chest full of gold coins to pay those metaphorical interest costs; but it comes with real, non-metaphorical hits to the bottom line.
Of course, the old-fashioned human struggle with sub-optimal code had its own real-world costs, in the added time to deliver a feature and in the opportunity-costs of what could not be delivered while all that time was spent paying the tech-debt costs. That was the point of Mr. Cunningham's metaphor.
It might have taken eye-popping monthly cost numbers for our AI tools to prompt our CTO to bless a code cleanup effort, but the end result will be a cleaner, leaner, healthier codebase for our future. And that will make everyone happy - the engineers will find more enjoyment in their labours; the company will benefit from increased velocity in our development; the finance team will be happy with the dropping costs for our AI usage; and the CTO will enjoy the glow of successfully raising our overall team productivity.