The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt.
When does this architectural debt actually make sense? Should it always be repaid? How can we constructively reason about technical debt, before and after incurring it? The question often boils down to another question we are familiar with: what is the value of software architecture, this invisible ingredient of many challenging systems?
This video explores different facets of technical debt and the various means that have been proposed to assess, mitigate, evaluate or reduce technical debt. It looks also at it as some form of a tactical investment, when technical debt is not just a “bad thing” as long as incurred in full knowledge on the consequences.
[youtube AAQqfWNMp6w]
Video Producer: Agile Vancouver
Technical debt is a great analogy. However I think there is another kind of debt often overlooked because it’s not as obvious to engineers at technology related stuff. That’s UX debt. UX debt is the like the carbon impact of software. Not obvious in the short term, not as readily visible. If you don’t measure it, you don’t know it exists. Only problem is it does exist. Just ask Oracle or SAP.
Jon
Twitter: @innes_jon