A few weeks ago someone had a fantastic post on Refactoring entitled, “You keep using that word, I’m not sure it means what you think it means“. I’ve started to get the feeling that this true for Technical Debt also.
Last week the always (in)credible Aslam Khan did a talk last week at the monthly SUGSA event on Technical Debt, which again got me thinking about this topic.
I think when Ward Cunningham coined the phrase “Technical Debt” it was a bit like the first time you hear the word “Schadenfreude” and realise that you’ve had a feeling all the time but never had a word for it till now. And then we began using the word for everything we tried to avoid doing. So I’d like to propose a new taxonomy for technical debt.
Undone Work
The first category is taken from Ken Schwaber’s “Scrum Guide“. Ken has a knack for picking words which drive a sense of urgency (see backlog). In Ken’s description of “undone work” he picks items which indicate a failure in the team’s ability to deliver “done-done” software. As agile coaches, new teams we encounter typically have fairly time consuming processes for releasing software. Build scripts which are not automated. Manual regression testing processes. Manual release processes, copying files, endless checklists of actions. All of these things are non-value adding in the customer’s eyes, but need to be fixed in order to allow the team to improve. Fixing this is necessary, but in my view, this is not technical debt. Firstly, and most importantly it does not conform to Ward’s fundamental assumption about technical debt, namely that it should be accumulated as a conscious decision.
Mess
“Uncle” Bob Martin coined this term for the crap we accumulate and we call technical debt. It reminds me of a term from Phillip K. Dick’s masterwork, “Do androids dream of electric sheep?” – “kipple”
Kipple is useless objects, like junk mail or match folders after you use the last match or gum wrappers or yesterday’s homeopape. When nobody’s around, kipple reproduces itself. For instance, if you to go bed leaving any kipple around your apartment, when you wake up there is twice as much of it. It always gets more and more.
No one can win against kipple, except temporarily and maybe in one spot. |
| From Do Androids Dream of Electric Sheep?, by Philip K. Dick. |
You may recognise this as a restatement of the law of entropy. I’ve also heard this referred to as “bit rot“. The reality is that without strong supporting technical practices (or to put it another way, eXtreme Programming) the tendency is for any system to accumulate mess over time. Without the conscious effort to improve the code base over time, the unconscious degradation over time will eventually overwhelm. For me, this is the most common route to a “design dead” product.
But this is not technical debt either; it’s still being accumulated unconsciously. We usually have no real handle on how much mess there is in a code base (although static code analysis will give you an indirect indication). As a result we have no idea of what the required effort will be to rehabilitate the code base. This is also usually the kind of code base developers itch to re-write. This is because they feel things are so bad, that is not possible, (never mind feasible) to tame this beast.
If you find yourself with a code-base like this what you need more than anything else, is information. You need to understand what the extent of the mess is. As mentioned static code analysis (duplication, cyclomatic complexity, code coverage, unused code paths) will assist in quantifying this. The Cutter Consortium is now offering services to help with that, all the way through to measuring the cost of your technical debt. This is likely overkill for many; but establishing both a baseline and a trend over time in these measures will assist in the prioritisation of technical debt.
Next what you will need is a strategy to clean up this mess over time. And then; START! The longer mess is allowed to accumulate the longer it will take to clean up. Also key to the long term success of this program is education; everyone in the team, including the Product Owner needs to understand what this mess is and how to clean it up and keep it clean. A good way of doing this is in regularly reviewing the “Definition of Done” and making sure that this attention to quality is maintained and extended over time.
This lesson of focusing on quality was primary in the work of Edwards Deming and remains a key path to unlocking the value of an agile team.
Design Debt
For me, this is the only real kind of technical debt. This is a conscious decision where the choice of design is explicitly constrained by the implementation time. And again here, I agree with Uncle Bob. That if for example, under time pressure you decide to use a hard-coded value & case statement rather than an enumeration, you’ve incurred technical debt. But you better be writing a clean implementation, with clear naming conventions, which meets all your team’s required “Definition of Done”. And this choice needs to be tracked explicitly; the clean up of this constrained decision should be tracked in your backlog. It should appear there with an estimate of sizing to clean up.
A tip I can pass on from one of the teams I’ve coached is to make use of a visualisation of the pain technical debt causes. Every time someone in the team is negatively affected by the piece of technical debt, add a sticky dot to it. When the time comes to groom the backlog, it should be easy to identify the most painful (and hence valuable) piece of technical debt to clean up. This helps the team and the Product Owner prioritise technical debt stories. Just having this in your team room can provide a healthy relief to the team.
The reason I think I hardly ever come in contact with this form of technical debt is because so few teams have a truly collaborative relationship with their Product Owner. It is only when the decision to take a design debt on is made through discussion and deliberation that it truly is technical debt. The real value of agility and agile teams is only unlocked when we collaborate.
Posted via email from scrumsense’s posterous
No Comments » | 
Coaching | 
Permalink
Posted by Peter Hundermark
As a 
.