What Is Technical Debt? | Definition and Overview

Many people get confused between technical debts and non-functional requirements. Defects can't be technical debts because technical debts don't mean not meeting requirements either functional or technical. Technical debts are related to poor design, poor coding or not having applied appropriate design patterns, etc.

Whereas defects are not meeting requirements, products not fit for use or poor performance, etc. Many times these confusions are created by agile doctors (agile coaches). Maybe those doctors are not from a development background or haven’t written a single line of code in their lifetime. They don’t understand the difference between technical debts and non-functional requirements. Not meeting non-functional requirements means there are defects and those defects can't be considered technical debts.

Below are some examples of both technical debt as well as a non-functional requirement. Please read and let me know if you feel I have mentioned anything incorrectly.

What are technical debts?

Martin Fowler has described this very beautifully here. But just to make it easier to understand I am adding some examples that I have faced in the past.

1st Example

I was working on an insurance product in 2007 and we were developing a portal. The actual product was WINS (AS 400) and we were tasked to create a portal using asp.net.

Since the backend was AS400 there was another team writing middleware using BizTalk. The middleware team was developing services and we were supposed to consume those services to write front-end using asp.net.

We started very well but as time passed we were running behind schedule. Every time we needed any change, we contacted the middleware team to make a few changes in the service layer but they were usually over-occupied with too many changes and taking more time to respond.

Since pressure was increasing day by day the front-end team started bypassing middleware and started pointing to the backend directly in order to reduce time in fixing defects. We were able to fix defects and deliver it on time. We did maintain a log for all such changes so the middleware team can fix them permanently in the future.

Unfortunately that future never came but that resulting in increased technical debts because new changes were taking more and more time just to investigate how to fix and where to fix. So basically we did well initially in launching portal on time but subsequent changes took more and more time wherein it was supposed to be taking lesser time as the team was more experienced by then.

2nd Example

Another case with same product, There were many business rules for generating policy. Those rules were driven through XML and we were using rules engine. There was a method for policy generation which was linked to rules engine and there was a single parameter for that method initially.

As development progress, many team members changed due to various reason. Every new developer has added some more lines of code but they were afraid to make any changes in existing code due to fear of breaking already working functionality. There wasn’t any good documentation either and that created more fear among new developers.

Result was horrible. Same method was having more than 10 overloading methods and more than 100,000 lines of code after 18 months. Nobody tried to refactor code to simplify it. Functionality was perfect but code was a disaster. Every time it was taking 2-3 weeks for new developers just to understand what had been written.

3rd Example

There can be design debts as well and here is an example. We were developing an EMR application in 2009 using WPF, WCF and SQL Server. WPF was pretty new and there wasn’t many experienced developers available but still team decided to learn and develop. Learning took more time but still team were not very confident about MVVM design patterns but business wanted to release it faster.

Team moved forward and started building it without having much understanding about MVVM. Result was good but they wrote code that wasn’t easy to understand and also added lots of extra codes that complicated whole things. We did similar things with another application using Silverlight at the same time.

The items mentioned above are not defects but rather debts. These debts typically arise due to the following reasons.

• 1Business pressure – Business care about functionality and not about code quality.
• 2Parallel development – When a team try to meet deadlines by putting more people.
• 3Lack of technical skills and knowledge – Not investing enough on learning good practices such as TDD, Refactoring and emergent design etc.
• 4Lack of documentation – Misconception nowadays due to poor understanding about agile. Where people think agile means no documents or don’t understand the value of living documents.
• 5Lack of ownership – This is very common when you outsource your development because many time outsourcing company don’t take ownership.
• 6Poor design skills – Again very common when you engage low-cost engineers with less experience. Many more. Check here

What is non-functional requirements?

As I said above, non-functional requirements are requirements, not technical debts. If pages taking more time to open and business complains about it then don’t consider it as technical debt. This is a requirement and not meeting requirement means defect. Team has to fix this. Similarly, if system not able to handle load or error messages are not clear means there are defects, not technical debts.

Below are some examples of non-functional requirements. Not meeting these means there are defects and not technical debts. Data security Managing user sessions and securing it Server load management during pick hours and non-pick hours Page loading time Server response time Proper log management Government compliances etc. I hope the above will help you to understand technical debt and what not technical debt is. Still not clear then reach out to me.