Refining the definition of technical debt
April 22, 2016
At a Dagstuhl seminar, sponsored by the Leibniz society, a group of experts tried to refine and agree on a common definition of the elusive concept of “technical debt”:
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.
(starting from Steve McConnell’s definition)
Very good, why don’t use this definition in wikipedia?
Why should Technical Debt be limited to -internal- system qualities? A decision to retain, or remove a legacy interface can incur Technical Debt, but has external properties. Similarly limits on capacity would have impact on external properties.
If you removed ‘internal’, I think I’m OK with this. (I think that Technical Debt can also imply to other kinds of man-made systems, but I’m OK with this definition focusing on ‘sw-intensive’ systems as long as it’s not limited to them.)
That a definition that I like. One reason is that it does not point at anybody. Most technical dept definitions point at somebody – in most cases at software engineers. And pointing at somebody never is a good way to improve.