Aug 10

Technical Debt: The definition from the Dagstuhl seminar 16162

The goal of this week-long seminar in Dagstuhl, Germany, was to establish a common understanding of key concepts of technical debt and build a road map for future work in this area.

At the conclusion of the seminar, the 33 participants agreed on the following definition of technical debt, which is refered as the 16162 definition of technical debt:

“In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.”

See more details on this seminar here:


Mar 15

What Managing Technical Debt means

Being able to estimate the Technical Debt of an application is a good point. With historical data, it allows to monitor the debt and detect progress or regression.

But developers need more, they expect to manage their technical debt. That means to be able to understand and analyze the debt. They need to be able to assess the level of risk associated to their technical debt. They need guidance for setting priorities for reducing this debt. They want to optimize their resources and expect to get the best ROI of their improvement activities.

Managers on their side want to manage the technical debt at portfolio level. They expect to be able to estimate, analyze and understand the technical debt of their complete portfolio. They would like guidance for identifying highest risks and allocates refactoring, improvement budget. Read the rest of this entry »

Mar 15

The benefits of the Technical Debt concept

Technical Debt is a powerful metaphor which is used more and more often at all levels of an IT organization. The concept has been defined and strongly supported by the agile community, but it applies to all kind of developments and all types of languages. Whatever the unit you use for measuring the debt (dollars, hours, work units etc.), the figures are easy to understand and to handle.  It tells you how far you are to your coding standard compliance. This way of measuring code quality provides at least the following benefits:

  • It provides an “easy to understand” and common language for all teams and their management.
  • It can be easily compared with other familiar measures like delay and costs.
  • It allows monitoring ¬†trends and performing comparisons.

In addition to that you get the benefits of a “true” measure:

  • It is objective. The amount of technical debt could be measured (or at least estimated) by automated analysis tools and so would not depend on subjective opinion. Read the rest of this entry »