thoughts from the test eye

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

Quote taken from Ward Cunningham in “The WyCash Portfolio Management System” [1] from 1992. Martin Fowler further elaborates around the subject “Technical Debt” [2] and identifies the “Technical Debt Quadrant” [3], where he makes a distinction between prudent and reckless debt as well as deliberate and inadvertent debt. These four debts creates the quadrant, as Martin sees it. Uncle Bob points out in his article “A mess is not a debt” [4] that some deliberate shortcuts should not be considered as a technical debt, but instead are just a mess. I think “A mess” could be seen as Broken Windows (another metaphor) that in the end turn into a debt you must pay, thus I agree with the comment that Daniel Broman had. Steve McConnell discuss the intentional and unintentional technical debt in an article [5]. He also elaborates around short-term and long-term debt. One among many important suggestion that he brings up is to maintain a debt list connected with workpackages needed to pay off a specific debt.

If the shortcut you are considering taking is too minor to add to the debt-service defect list/product backlog, then it’s too minor to make a difference; don’t take that shortcut. We only want to take shortcuts that we can track and repair later.

The quote above from Steve McConnel implies an openness to the debt that I like. It also implies we should focus on debt that we make a strategic decision on. The comments to this article also sheds more light to debt metaphor. Andy Lester has a talk in “Get out of Technical Debt Now!” [6], where he identifies many issues that are not strictly technical but instead more in the  social domain. There are many aspects that I agree with, but I would consider them as another kind of debt.

Ted Theodoropoulos has a series of articles where he defines [7] Technical Debt, then goes into how to identify [8] it, how to quantify [9] it, how to plan a remediation [10] and finally how to governance [11] it. Ted goes deeper than the previous authors have gone and is perhaps a bit more structured in his definitions, as I see it. Still, the sum of all views from all authors is imporant. All of these developers use the Debt metaphor to make it easier to communicate to different stakeholders.

By now you should have a good understanding what Technical Debt is and perhaps have some ideas on how we, as testers, can help our fellow developers with the Technical Debt. None of the authors above mention the usage of testing or QA in this. If we know there is a technical debt that is ever increasing, why is it so seldome that we talk about it openly in the project between tester and developer? It is a fact that developers cannot leave the code in as good shape as they always want it and that they must take shortcuts. Some of the authors above have stated to have a list of these shortcuts, open issues and bugs before hand. This would give us testers lots of valuable information that would make our testing even better. If the technical debt is a continuous struggle for the developers, we as testers are there to help!

Jonathan Kohl has touched the subject before in this article about “Testing Debt” [12] that partly relates to the subject. Johanna Rothman has in her two articles about “What Testers Can Do about Technical Debt” [13] and [14]. I will try to build on their ideas.

1. Work closer to the developers, gain their trust. Assist them so that you understand when certain shortcuts are not sloppyness, but deliberate with known risks. Bugs found in these areas might not be a big surprise to them.
2. I would improve communication within the project to a such a degree where we can talk about the technical debt (and possibly testing debt) openly and so that we can start pinning down the debt lists, assuming we have both testing debt and technical debt (developer debt). With testing debt I am referring to my own definition in the article “Turning the tide of bad testing” [15]. Still, there are many aspects of the debts that are social factors that are not so easy to talk about, but does that mean that we should not add it to the list? It might be that it is too hard to mix the issues that are directly related to code with social factors. In that case we might be talking about different kinds of debt for different situations and decisions.
3. I would assume that the developers know which content in the of debt list they will consider for fixing soon and which will be postponed for the far far future. We would be able to talk about what areas should have higher priority so that we can put focus where it belongs.
4. If we know an area is broken (dead horse heuristic) and that it will be fixed in the near future, there are probably other areas that could getter higher attention.
5. Areas which the developer consider are “safe” to postpone into the far future, we as testers could verify their claims of certainty or identify new risks that make them reconsider.
6. We could just see the debt as a risk area in itself. Test it and adding bugs as additional cost of having the debt left behind and as an aid to pinpoint where to get the most of a payback.
7. A tester could be involved in the decision for the strategic debt, perhaps to evaluate the decision and to look for possible issues that will threaten the outcome of increasing the technical debt.
8. Debt that is related to testability should perhaps be reconsidered. As testers, we would not be able to help out as much if this was threatened.
9. Try to talk openly with developers about non-strategic debt (as Ted defines it), thus areas which has poorly written code or something similar. By being open about the situation will enable you as tester to help out more.
10. When development start to payback on the debt you can work closely with the developers to decrease the introduction of new bugs and new areas that increase debt.
11. …

What would you consider adding to this list that I have left out?

References:

[1] The WyCash Portfolio Management System – http://c2.com/doc/oopsla92.html

[2] TechnicalDebt – http://martinfowler.com/bliki/TechnicalDebt.html

[3] Technical Debt Quadrant – http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

[4] A mess is not a technical debt – http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt

[5] Technical Debt – http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

[6] Get out of Technical Debt Now! – http://www.media-landscape.com/yapc/2006-06-26.AndyLester/

[7] Technical Debt – Definition – http://blog.acrowire.com/technical-debt/technical-debt-part-1-definition/

[8] Technical Debt – Identification – http://blog.acrowire.com/technical-debt/technical-debt-part-2-identification/

[9] Technical Debt – Quantifying – http://blog.acrowire.com/technical-debt/technical-debt-part-3-quantifying/

[10] Technical Debt – Remediation – http://blog.acrowire.com/technical-debt/technical-debt-part-4-remediation/

[11] Technical Debt – Governance – http://blog.acrowire.com/technical-debt/technical-debt-part-5-governance/

[12] Testing Debt – http://www.kohl.ca/blog/archives/000148.html

[13] What Testers Can Do about Technical Debt – Part 1 – http://www.stickyminds.com/s.asp?F=S3629_COL_2

[14] What Testers Can Do about Technical Debt – Part 2 – http://www.stickyminds.com/s.asp?F=S3643_COL_2

[15] Turning the tide of bad testing – http://thetesteye.com/blog/2010/11/turning-the-tide-of-bad-testing/