Two Takes on Technical Debt
At InfoQ, reporter Amr Elssamadisy recently posted an article considering technical debt. Most teams—especially those who work with legacy systems—understand the dangers of technical debt. In short, when the quality of code suffers for the sake of expedited development, the team accrues what is called “technical debt.” Ideally, the team “repays” this debt by fixing sloppy coding and bugs before writing more code. So, to extend the budgeting metaphor, a development team should strive to “live within its means,” addressing technical debt when it accumulates, rather than moving forward and amassing more. In the InfoQ post, Elssamadisy considers whether technical debt is a technical problem or, as he asserts, a symptom of a larger organizational problem. That is, could technical debt be prevented by imposing more rigorous coding standards or utilizing agile development techniques, like test-driven design? Or is the fact that this debt is primarily visible to the development team the more formidable threat?
I’d love to hear what you think about this issue. Please share your thoughts in the comment section. If you’re looking for further reading on the topic, I’d highly recommend you download the whitepaper “Technical Debt and Design Death” by CSTs Michael James and Kane Mar.