In some circles today technical debt or “tech debt” has a negative connotation.  However, when Ward Cunningham (one of the original signers of the Agile Manifesto) first coined the term, we believe he was trying to convey the costs associated with deferred maintenance or investment in technology. Blog Graphics ACSM vs SASM 3Unfortunately, it appears that over time, the term has occasionally come to be misconstrued as a poor reflection of the technical team.

The term “debt” can be equated with “failure” which leads to misconceptions about how and why technical debt came into existence in the first place. We incur technical debt when we focus solely on feature development, when the timeline is paramount above all else, and less drastically, over time as systems and technologies age. 

We can combat the “shame” of technical debt by rephrasing the term as “technical maintenance.” This allows us to reframe our perceptions and check our biases. The work is the same (both the accumulation of maintenance activities and how they are addressed), but the stigma is gone. 

Anyone who has invested in a high value item can relate to the responsibility of protecting that investment with ongoing maintenance – be it a car, a home, or even a bicycle. Each one of those items requires regular maintenance and care in order to continue to provide value to its owner. It is the same with software products. Businesses spend millions of dollars to build software products and part of protecting that investment is through a commitment to maintaining the product.


Cost of Change

The choice to defer maintenance should be a deliberate one. Sometimes it is a necessary choice, as the team optimizes how to balance the needs of the system with the needs of the customer and of the business. Focusing purely on technical excellence at the expense of delivering value to the customer is never a winning proposition. Instead, it is a constant balance of choices. 

Over time as the maintenance work accumulates, the cost to address it accumulates as well. Jim Highsmith described this as the “Cost of Change (CoC)” in his initial blog post “The Financial Implications of Technical Debt” (since removed). 


An increased cost of change brought on by an accumulation of technical maintenance tasks, decreases the team’s ability to quickly respond to customer needs, lowers predictability, and typically leads to dissatisfied customers, stakeholders, and sponsors. 

To combat this issue, the team needs to adopt a dedicated maintenance schedule and work collaboratively with the business to ensure time is consistently allocated towards this work. 

Just as one maintains their home with daily, weekly, monthly, and annual maintenance (or incurs the cost of delay, with interest), the team must continually maintain the product suite. 

Table for WordPress Blog Posts


As you continue to manage your technical maintenance work, it is important to make deliberate and transparent decisions about how open items will be addressed. 

  • Undergo Full Maintenance – Take the time to refactor or replace non-working or non-ideal solutions.  
  • “Quick Fix” Maintenance – Partially address an ongoing maintenance issue by making small code changes to reduce the impact of the maintenance issue without fully eliminating the larger problem. This is the “good enough” solution that is sometimes necessary to keep things moving. 
  • Defer Maintenance – The deliberate and conscious choice to live with the necessary maintenance work as-is while other work takes priority. This is an expensive, but sometimes necessary, choice. 

Each form of maintenance (or lack thereof) is a choice with downstream consequences. As with all business decisions, the investment decisions need to be weighed against the full scope of the business and customer needs.



Decisions large and small can lead to technical maintenance needs. It’s vital to build in time to maintain your product suite on a consistent basis. Build technical excellence into your products by dedicating time daily, weekly and monthly to the maintenance tasks required to keep your product running smoothly. 

We at LitheSpeed welcome further dialogue with potential customers who are looking for experienced and expert Agile and Lean partners for their implementation efforts.

Please contact us here.