Skip to content

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 →
  1. April 22, 2016 04:25 UTC

    Very good, why don’t use this definition in wikipedia?

  2. April 22, 2016 05:50 UTC

    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.)

  3. November 19, 2016 04:28 UTC

    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.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: