Technical debt: we've all written about it; I've described in my book, Project Management the Agile Way (see below), but I guess the industry has never settled on a formal definition.
I've always thought of it as a "punch list" that is a "debt" that must be retired in the future .... stuff that needs to get DONE or fixed so that we can say to the sponsor: hey, it's DONE and the QUALITY is built in.
I saw this definition recently. Frankly, it's a little too formal and I think it actually misses the point that debt may be as simple as a low level test not completed; a color not made right; a functionality with a bug that occurs very infrequently, etc. Nonetheless, here it is for your consideration
In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability [SIC].
If you click back to the original source, you pick up on this explanation which adds a bit of color commentary, to wit:
Of course, I take a bit of issue with the last phrase "design trade-off problem at hand": technical debt is not exclusively -- or even -- about design trades per se; as before: it could be as simple as a low level test not completed. One wonders if the guys who wrote this stuff have actually ever done it.
This metaphor is in essence an effective way of communicating design trade-offs and using software quality and business context data in a timely way to course correct.
While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand.
While other software engineering disciplines such as software sustainability, maintenance and evolution, refactoring, software quality, and empirical software engineering have produced results relevant to managing technical debt, none of them alone suffice to model, manage, and communicate the different facets of the design trade-off problem at hand.
Of course, I take a bit of issue with the last phrase "design trade-off problem at hand": technical debt is not exclusively -- or even -- about design trades per se; as before: it could be as simple as a low level test not completed. One wonders if the guys who wrote this stuff have actually ever done it.
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
