The Deadly Silent Debt

I heard many times the concept of technical debt. I also realized it's terribly hard not to acquire it and it will keep increasing in your application all the time as you build it.

I will start with the first question...

What is technical debt?

Technical Debt is a detour from the right system to reduce development time.

It's called technical debt, because it behaves like a real monetary debt. You get a fully functional system without investing all the time and effort it needed to get it right. Just like a monetary debt, you need to return a capital plus interests. Depending on the amount of technical debt you acquire, the amount of interests will grow faster or slower. The sooner you pay your capital debt, the less you spend in interests. The longer it takes you to repay the technical debt, the interests will keep adding, making it at some point economically inviable to be repaid.

How do I acquire technical debt?

Well, as I said before, it's really easy to acquire it, temptation is always there to do the quick thing and keep going. I think there are four ways to increase your technical debt. A mix of intentionally, unintentionally, planned and unplanned.

Planned Intentional Technical Debt

The more formal definition of technical debt, implies it's consciously acquired to get something in the market faster to start making money sooner. That money that is made earlier on, will allow the company to survive or make the difference to repay the technical debt. Technical debt in this case, it's something planned and done intentionally. It's done as part of a business strategy which usually leads to a bigger profit. If it's planned correctly, and the risks are known it's not a bad thing.
Examples:

• We need to release the new version of the Iphone OS today, before Microsoft announces their Windows Phone 7 next week. We will add multitasking for Iphone 3GS now, and someday we will add it to the 3G too.
• We will release our next version of the application using the built-in user repository, and later on we will integrate it with CAS to support single sign on.

Planned Unintentional Technical Debt
Well, this is the the type of technical debt added into the system because of external constraints. It could be because you cannot get senior developers. It could be because another team in the organization needs something working in less than a week. It could be due to a corporate policy: We will only hire junior developers and train them.

We know we will be adding technical debt due to this constraints, so we plan for ways to reduce the capital we are borrowing. Also planning a way to repay the capital once the constraints are gone.


Examples:

• Junior members in the team might add technical debt because the lack of knowledge so we will do code reviews.
• Eventual tight deadlines might require the development team come up with a quick solution, and then refactor it to what we think is the right one.

Unplanned Intentional Technical Debt

In this case, I refer to the technical debt constantly added into the system. The unplanned intentional technical debt, is caused by constantly wrong desitions of management and the development team. This is the technical debt added when we are rushing things all the time. This is the type of debt added by the lack of a well defined development process or because it's not followed intentionally. This is the type of debt that rottens the guts of the systems and breaks the will of the ones who are trying to do the right system.
Examples:

• We will not be writing any test into the code because we are in a hurry this month. 
• Just add another if statement and move on, they want it today and we have a pile of work for 5 months waiting for us tomorrow.
• Submit the code now, I will do a quick check on the test server and then we promote it to production tomorrow.
• I need to leave early today, so I will submit my fix now, and someday I will fix it properly.
• I don't know how to use hibernate, so I will do it with a hardcoded SQL statement now, and hopefully someday somebody fixes it properly.

Unplanned Unintentional Technical Debt

This is very similar to the Planned Unintentional case. It's caused by the same constraints, but the big difference is that nobody plans or wants to spend time fixing them. This is due to resource constraints plus constant bad choices from the management team.
Examples:

• When we ask you to do the invoice module in two days, we thought you were doing it also right. 
• I cannot understand, you have 3 months of experience in java, and you never heard of the proxy pattern?. 
• I just added another IF there, there are already 30 of them in that method so I guess another one will do no harm.
• That java class with 10K lines of code started with just 5 lines a few years ago.

What can I do to reduce technical debt?

The first step would be to try to stop increasing the technical debt. I know, it's already a mess, all the developers complaint about it. Some of them would love to put the latest framework on it as it would be the silver bullet for your technical debt. And also, yes... you are right, each task will take you a lot longer now, as you need to fix countless problems for each thing you have to change. Yes, that's what you get by borrowing all the time and never paying it back. But, be sure that paying back some of it each time you have to do something, as little as it may seem, will make the difference

I can tell you how you can get more than 2 millions in technical debt. Borrowing one buck at a time. I can also tell you how you can repay it. Paying back one buck at a time. Of course, keep in mind it won't happen over night.

It's also very important to make technical debt as visible as possible. Having technical debt visible, will make the team to start taking it into account. Will help the team to stop increasing it.

Conclusions

I think planned debts, are not actually a problem in any company. Making technical debt part of your business strategy, when it's carefully planned, can be the difference of keeping your job in 2 months or not. Planning ways to mitigate technical debt your are not expecting and not doing intentionally is also a healthy way to do software development.

The unplanned debts are the problem. This is when technical debt is not considered and ignored by everybody. It becomes a deadly silent debt. It's deadly because the system will likely be considered to be rewritten even before it's finished, and it's silent because management doesn't want to hear about it. There is no worst deaf, than the one who doesn't want to hear. Without management knowing where you are, they will not plan ways to get you out of it.

Something is part of your behavior when you do it naturally and effortless. Something is part of your character, when it costs you more than you were willing to give for it. Managing and reducing technical debt must be engraved in management character, and not just part of it's behavior. That will be the only way for technical debt not kill your application.