Krishna Kumar is a software development manager from New Hampshire. He writes on topics related to software development, programming, project management, and business management. Krishna is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Reckless Debt versus Strategic Debt

  • submit to reddit

Chris Eargle has a great article explaining that the term “technical debt” comprises both strategic debt and reckless debt:

Technical debt accrues interest, and it must be paid back lest the interest payments (lost time) become too high for product maintenance and future development. If immediate business concerns outweigh future business concerns, it makes sense to incur this debt. Debt incurred in this manner is known as strategic debt and is the only kind I find acceptable. […]

There is another form of technical debt that can and should be avoided: reckless debt. Unlike strategic debt, this is suffered without an informed decision. Reckless debt is far more dangerous as it is typically ignored or obfuscated until it presents a more serious problem.

This is right. In software development, even though you do research and discuss and debate, sometimes you cannot make a clear final decision that only has advantages. Ideally you can compromise on what features you have to deliver, but sometimes you have to accommodate the stakeholders on other software attributes. For example, you may choose to go with an older, slower version of a library than a faster version that has not been battle-tested. If you understand the decision you are making, you know you have to fix the problem at a later point in time, and will have to live with the disadvantages in the meantime.

But if you are misinformed, or don’t have the skills, or are prejudiced, then your decision is reckless. I am not sure that “debt” is the right word because people know when they are getting into debt, even with loan sharks. Some terribly wrong decisions made in software development are done without any awareness. People are either ignorant, or they are dismissive of the possibility that the decision could lead to loss. For example, not paying attention to backups.

A quick word about messy code. If your team has a programmer who doesn’t know how to write reasonably good low-level code, it is not worth it. At the end, you will have to read and rewrite every single line of code that they have written. This rewrite is much more time-consuming and cumbersome than just writing the same code in the first place, because now you have to worry that something is not broken, and have to build unit tests around them and need time from testers. Sometimes the old code contains bugs that you discover and cannot fix because fixing them can create problems for existing customers who rely on an unexpected behavior of  the software.

There is a hygiene factor in code. Going below that threshold indicates a programmer with poor skills and lack of professionalism. For example, an incorrect or outdated use of naming, formatting, low-level program flow techniques demonstrates a poor programmer. But if you have some programmer who is good at the low-level, but has problems with program structure, such as making good choices of how to split or join methods or classes, or how to manage a programming interface, then a lot of code can be salvaged by re-assembly without worrying about low-level implementation details. Of course, the hygiene factor varies from one project team to another; you don’t want a team of architects making rookie design mistakes. Teams need to set their base threshold for programmer skills and only incur code debt for mistakes above it.

Published at DZone with permission of Krishna Kumar, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)