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)
3 Comments
leave one →
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.