What Is Your Technical Debt Ceiling?

This is a guest post by Isaac Shi,  CTO and Chief Software Architect, Prognosis Health Information Systems

The U.S. Congress and White House are currently engaged in a historic debate about the federal debt ceiling. Problems like these tend to accumulate over time, with longtime negligence and lack of action due to political inconvenience one reason for the current federal debt crisis.  As it happens, software development shares a remarkably similar pattern.

Technical debt is a lot like government debt; it carries an interest cost, it comes from short-term rapid enhancements without long-term planning, and is ultimately caused by a lack of balanced approach to addressing urgent issues vs. important issues.

Now believe it or not, some level of technical debt actually allows for an accelerated development time frame, as it reduces the tendency of over-engineering and generates immediate ROI in delivering features to clients quicker. After all, the market needs those features yesterday.

Once the technical debt is accumulated to a certain level, however, it leads to performance issues and restrains the flexibility of adding new features. This will eventually hinder the scalability, reliability and flexibility of the entire software system.

In order to achieve a balanced technical debt, or technical surplus, you should first be able to measure it. For this, I’d like to introduce a technical debt measurement concept within the Scrum framework: a software system’s technical debt can be measured by the user story points that could be created but are not due to the time used to serve all existing technical debt by code refactoring. Gross Development Product (GDP) should be the annual user story points output for a software company. So the technical debt ratio should be calculated as so:

Technical debt ratio = User story points used to serve technical debt / GDP

If a development team can produce 12,000 user story points per year, but is forced to devote effort that is equivalent to 3,000 user story points to refactor existing codes, then the technical debt of this software system is 3,000 user story points. Therefore, the technical debt to annual GDP ratio for this company is 25%, which may actually be at a sustainable level, depending on the industry you are in.

Every software company needs to establish its comfortable technical debt ceiling, as it can vary from industry to industry. But it’s important that companies reach a consensus on the technical debt ratio and have a plan to reduce technical debt once they approach that ceiling.

Development teams should always use evolutionary product design in feature development and continuous refactoring for the code base rather than resorting to a situation that requires stopping all feature development to only work on technical debt. Through this effort, one can reduce the technical debt while creating and maintaining a decent architectural pattern. Coders following these solid software design patterns can avoid software debt in the first place, even under the heavy pressure of deadlines. This is how technical surplus is created.

Scrum not only offers guidance for us when building new features, it also provides a similar principle to address technical debt  through incremental iterations by weaving architectural improvement inside feature building.

Of course, the best way to avoid crisis is to never get into one in the first place. If you do find yourself in a crisis, try to use it as an opportunity. In other words, you should always use it for the greater good of the software system. The solution created to respond to the crisis should not only solve immediate issues, but also address the underlying long-term architectural deficit so you don’t find yourself kicking the can down the road.

The economy can be boom or bust, and software companies rise and fall. A repeating scenario is that legacy software systems become so obsolete (with too much debt and baggage) that it’s much easier for a new company to build a new software platform to replace the old one.

Management of technical debt should be part of every software company’s strategic thinking, and it’s time for your company’s Barack Obama and John Boehner to reach an agreement on this.

Isaac Shi is Chief Technology Officer and Chief Software Architect with Prognosis Health Information Systems, a company focused on delivering solutions and services for hospitals and health care professionals. Isaac Shi of Prognosis Health Information Systems explains why technical debt management should be part of every software company’s strategic thinking in this guest post.