What is Technical Debt?

It is estimated by some that 80% of all costs associated with Software Development is NOT in the development and deployment of Version One but in the maintenance of the application throughout the Software Development Life Cycle (SDLC).

Technical Debt is a metaphor that is based on the financial concept of using credit cards to buy items that you cannot really afford to pay for with resources you have already earned.

Technical Debt Equates to the Sanctioning Poor Programming

… By Borrowing on a Corporate Development Credit Card

…… That Always has Ramifications and Hidden Costs Associated with the Action

This 400% cost increase is generally attributed to a Technical Debt decisions made at the beginning of the project.

Ten philosophies that charge on the credit card:

1. Stakeholders and Management belief that Developers are only Productive when Coding

2. “Plan your Work and Working Your Plan” does not apply to our software development

3. Technical Debt can be ignored for now, we just need a working product

4. Get the application to market as soon as it is just functioning  at any level of quality.

5. “We Can Fix It Later”, which generally never happens

6. Experienced Architects are way too expensive, we can design it as we go

7. Code Review takes too much  time out of the development day

8. We can’t afford developers that develop in best practices

9. Test Driven Development (TDD) cost twice as much as traditional development

10. Maintenance Developers cost less than the original Developers

These Corporate concepts generally change only
after the pain of reality becomes unmanageable
for the Finance and the Business Stakeholders

The Reality of the Cost Technical Debt

The consequences of the above philosophies is that it is difficult to quantify the 80% cost of Technical Debt.

As most companies do not track the actual cost of their application development over the application’s lifetime it cannot be quantified the costs in a way that can be managed.

The CFO sees the initial costs and the total yearly expense of maintenance of all company applications without the ability to aggregate a single application’s lifetime cost.

The Real Application Expense Occur when

… With New Features and Functionality

…… And Bugs Found by the Customers  

Major costs occur when new releases of dependency assemblies are deployed.

Subtle bug artifacts created by poor design and implementation are expensive to locate and resolve.

These expenses are rarely associated with the cost of the application.

The application that is designed and developed as a Tightly Coupled with Low Cohesion solution will be difficult, if not impossible, to make even the simplest of feature enhancement during its life cycle.

An application that doesn’t include a Test Suite of Unit and Integration Tests runs the very real risk of hours, if not days, of troubleshooting when changes are made in related subsystems.

The Best Defense is a Great Offense

A Developer must internalize the concept of Design Principles of successful developers.

Decades of failed projects have produced Code Standards to aid the developers to deliver solutions to their Client’s that help to prevent the problems of Technical Debt.

You Can Manage Technical Debt

… And Still Make Business Deadlines

Not all Technical Debt is Bad!

As Steven McConnell, author of Code Complete 2, discusses this concept in his presentation on Technical Debt during his Technical Debt Webinar:

When managing Technical Debt evaluate the overall cost of the charge on the Technical Debt credit card.

If the Principle and Interest payments are affordable when the code is developed then consider borrowing on the Corporate credit card.

When the cost becomes unmanageable, such as the third time the poor code is touched, consider paying off the debt.

This is a paraphrasing of the concept but the intent is sound. 

Business requirements do force borrowing on the Corporate Technical Debt credit card but a vigilant due diligence process must be in place and implemented daily.

Technical Debt, Agile, and Sprint Iterations

Technical Debt can be effectively managed within the Agile Sprint development methodology.

The Sprint Backlog is an excellent tool to manage development Technical Debt.

In the course of Sprint development, when Technical Debt is discovered, and cannot be paid off at that time, add a Task Assignment to the Backlog as Technical Debt.

By “Running it up the Flagpole” you remove Technical Debt from the deep dark corners of development and bring it into the “Light of the Development Process“.

By creating a Sprint Development Task assignment process that assigns Sprint Tasks only to the Wednesday of the last iteration week you create a development environment that supports two days per developer to pay down the Technical Debt. 

This process also creates headroom for a higher degree of Sprint Task completion success. The Scrum Master, with the Product Owner, can assign the “Low Laying Fruit” of Technical Debt.

This creates a dynamic in the development community that supports Technical Debt, when required, and prevents the cost of Technical Debt from becoming out of control.

The CFO and Management will appreciate your efforts
and you will deliver manageable code:
“On Time and on Budget”

Wisdom Pearl # 116 – The Modern Developer’s Mantra

I Will Practice My Development Art First

… And Practice My Chosen Science Second