Burdened with technical debt

Incurring intentional technical debt should be a business-based decision. This doesn't mean that business people need to be involved, but every time you make the decision to take the quick and dirty approach versus doing the right thing, there should be a solid reason behind it. That solid reason should be: this is better for the business. I know this sounds like something out of Office Space, but every time you copy and paste code, every time you don't refactor, every time you violate a naming convention, every time you choose to leave a defect in the product, every time you write code without a test case, you should be doing it because it makes good business sense. At the end of the day, the software we write serves the business and is supposed to add to the bottom line.


Sometimes it makes sense to incur technical debt. Products can be shipped with defects and sometimes getting to market first or with a splash makes more sense than spending the time (read money) to get the architecture right and the code tight. If the business earns more money by first shipping a product, then addressing technical debt than it would by addressing the debt up front, it makes good business sense to incur that cost.

However, not all technical debt is intentional or considered in these terms. Teams under perform, make bad decisions, lack the required technical skills or just don't care. The business may not even realize it is taking on this type of debt. The product may sell and perform well, but over time it will become burdened with so much accidental debt that it becomes bloated too hard to innovate.

What happens when a product becomes burdened with technical debt, intentional or accidental? From my point of view, just like being burdened with too much financial debt, there are no good choices or easy answers. You can:

• Rewrite the software from scratch
  
• Refactor and incrementally improve over time
• Pay down your debt in a large chunk
• Live with it
• Find a new job

Scratch Rewrite

If you've got the time and the money, this might be a viable solution if you can sell it to the organization. You get to re-write the product with knowledge of already having a working system. However, it is expensive and at the end of what could be several years, you have a product that has the same functionality as your original code base, but with new and exciting bugs. In the mean time, you have to support the existing software and hope that the organization doesn't decide to change course or scrap the re-write.

Refactor and incrementally improve over time

You can try and pay down your technical debt over time. Refactoring and code clean up should be something you do as part of your normal development process. It is a great way to understand and improve the code and reduce defects. But refactoring and code clean up is not a viable strategy for paying down large technical debts. First off, it reduces the team velocity towards new features that can actually be marketed and produce new revenue. Second, you may be solving the wrong problems: it may be hard to address architecture problems in the limited time and divided attention spans that will be in play when you are both innovating and refactoring. Finally, it just may not be feasible to pay down the debt by making the minimum payments. Consider that it takes 23 years and $7000 to pay down a $5000 credit card debt making the minimum payments each month.

Pay down your debt in a large chunk

Similar to a re-write, but instead of starting from scratch and building new software from the ground up, you could dedicate all or a large portion of the team to swarming and focusing on paying down technical debt for an intense, but fixed period of time. This could potentially reduce your technical debt to the point where you can again innovate and rapidly produce quality and important software. But, you'll be spending a lot of money, you may not be successful in removing enough debt, and while you will have less technical debt, you won't be free of it. Additionally, if your debt is fundamentally architectural, you may not be able solve the right problems with limited time and unless you fundamentally change your development practices after swarming you'll only have delayed the problem.

Live with it

You could decide just to acknowledge and live with the technical debt. This is untenable in the long run and eventually you will spend most, if not all of your time, fixing defects instead of adding new value to the business. Innovation will be stymied and it will take more money, more people and more time to develop new features.

Find a new job

This may be the best personal decision. This is obviously not good for the business unless you are a NNPP, but if you enjoy designing and developing new software and creating value, them this might be right for you. Just make sure you learn from being burdened with too much technical debt and avoid the problem in the first place in your next job.