Great article! I’d like to reprint this post on pmboulevard.com in our January 19 issue. Please email me to talk specifics.

Best Regards,

Jen Girdish

So, we ended up with a Regression Test Suite Debt, in that we had no automated regression tests and no performance / load tests against which to measure the system at the end of a long big-bang rewrite.

We took steps to correct this by introducing automated testing using Selenium and web load tools.

However, convincing reluctant management who already see a project over-budget and running longer than they wished is not an easy task. Eventually we adopted Scrum and other agile practices to help us prioritize on delivery requirements.

When it comes to debt that is piling up, you really have to operate on principle. This means you probably have to “draw a line in the sand” when you know that the debt is too large and it must be addressed NOW, before disaster occurs later.

This does not mean you do not negotiate, far from it. However, you must set forth the principle that you, as a technical person, will not proceed with decisions made by someone else that you feel are ill-advised and worsen the debt. If you ever feel pressured into into making decisions to continue piling up debt, think about this:

1) If you accept the decision and proceed, and utter failure occurs as you predicted, does it make it any better that it wasn’t your decision in the first place?

The likely answer is no, it does not make it better. There is very little satisfaction in seeing a failure occur that you had anticipated and failed to prevent, regardless of whether it’s your decision of somebody else’s.

2) If you argue the decision and insist that the debt must be paid down, what is the worst that could happen?

Will they fire you? They likely will not. If they do, you’re probably better off elsewhere anyway if you’ve been warning of the debt for a long time and they continue to ignore it.

3) Finally, sometimes you can remind them that the reason the debt is high is that they made decisions early on not to slow down, knowing that the debt would have to be removed later. But, make sure they understand that THERE IS DEBT. If they don’t even believe that there is debt, then your task is more difficult.

Finally…

After all is said and done, the team as a whole is responsible for the quality of a system, not one individual. If a team denies responsibility and blames “management decisions”, then the team has not tried hard enough or has not been smart enough to solve the problem.

Development, in groups larger than one, is a team sport, and that is why the Scrum metaphor works well. It is not easy, and it requires constant communication and attention, but

Is this your own innovation or do others use a similar categorization? Up until now I have considered Software Debt and Technical Debt to be synonyms and included the other aspects within.

Except I think that Configuration Management Debt and Platform Experience Debt are more symptoms of Software Debt rather that components, or causes of it.

Also thought provoking is the idea of listing technical debt payback tasks in the same list as all other tasks, which implies, to me at least, that we can quantify it in the same way as the other tasks for example as story points.

I look forward to your further posts on the topic.

As a software house that delivers bespoke software solutions to corporate customers we grapple with the issue of managing ’software debt’ in the context of getting the customer to understand the issue enough to justify the budget for re-factoring. This is not always an easy task.

Our development team continue to explore the best ways to enact the principles of agile development and translating that into a commercially viable offering.

Experience plays a big part in judging whether there is sufficient time in the schedule of a project to allow re-factoring to occur even if the benefits and long term advantages are clear.