Much has been written on technical debt (e.g. see Fowler’s bliki, the c2 wiki or Ward Cunningham’s Youtube video). For me, Technical Debt is a metaphor for the price we pay for the eventual consequences of poor technical choices.

A way to make this visible is by defining detailed measures for quality, analyzing your code and product and then present a number or grade - see for instance Fitnesse’s SonarQube. I must say I appreciate the effort and I can imagine that this is useful. However I also find these measures difficult to understand - which does not deem them useless, but does mean less technical stakeholders and team members are likely to have a hard time interpreting them too.

Technical Debt is hindering innovation and as such it is an important aspect to monitor - on the management level. I think it is important to be transparent with respect to the level of the technical debt we experience. I also believe it is slightly more fuzzy than the SonarQube suggests.

Therefore I like to “measure up” technical debt by querying the developers using five questions.

Technical Debt survey

1) I don’t experience friction caused by poor technical choices while working on new features.

strongly disagree (1)(2)(3)(4)(5) strongly agree

2) I rarely spend any time on cleaning up code caused by poor technical choices.

strongly disagree (1)(2)(3)(4)(5) strongly agree

3) In my opinion, our technical debt is

reckless (1)(2)(3)(4)(5) prudent

4) In my opinion, our technical debt is

inadvertent (1)(2)(3)(4)(5) deliberate

5) What bothered me most during development this last sprint was:

Open question

The numbers are collected each sprint, using a Google form. We combine these numbers into a technical debt score, which we monitor and present on the team wall.

How do you visualize technical debt? Any suggestions on improving the wording n the survey?



blog comments powered by Disqus

2017

August
July
June
March
February
January

2016

November
June
May
April
March
February
January

2015

December
November
October