You can more aggressively remediate debt if you have more monitors, right?

You can more aggressively remediate debt if you have more monitors, right?

One of the more enjoyable parts of writing these blog entries is the interesting conversations I get into.  The conversation I had at 3:30 AM this morning was even more interesting than normal (I was discussing this topic at 3:30 AM because I needed to find a convenient time for a multi-time zone phone call that would not conflict with running a 10k before 8 AM!) The discussion was about whether an aggressive approach to remediating technical debt can have measurable productivity benefits. My friend had some data that argues that technical debt should be remediated continually (at least at some level).

In my experience, most organizations only react to technical debt when it reaches some trigger level.  That is not to say that that they don’t attempt to avoid technical debt through reviews, pair programming, tools and other techniques as a normal practice.  There are two basic categories of triggers.  The first is a limit that fits into the organization’s scheme for measuring technical debt. The second is when someone decides that too much time or money is being spent just on keeping an application or portfolio running.  When the latter case is extreme, words like replacement or outsourcing tend to get used, rather than remediation or refactoring. In either case, the logic is that effort and budget is better spent on delivering functionality than on refactoring, until the technical debt begins to impede progress.

My friend suggested that rather than waiting, some portion of all project time should be consciously and publicly committed to remediating known technical debt above and beyond the normal technical debt avoidance techniques.  The argument is that the technical debt is very similar to the scenario that teams face when they decide to improve how they will work in a retrospective.  We could easily say that addressing issues found in a retrospective represents the remediation of process debt.  Why wouldn’t we pursue technical debt in a similar manner? I think the logic is hard to argue with, if it can be shown to benefit the customer and the organization.

As noted earlier, my friend came with data.  My phone friend described two moderately mature Agile teams. Both teams included 7 people, were mostly dedicated resources (did not work on projects outside the team), most people on the both teams had been together doing a mix of Scrum, xP and lean for 3 years, and that they have approximately the same level of technical capability. The organization uses IFPUG function points to measure team productivity to identify macro level process improvements and best practices.  One team actively includes one story each sprint to either refactor some portion of code or to address a specific item of technical debt from their backlog.  The other does not follow this practice.   The data from the last three quarterly releases is shown below:


Team Apple was the team that actively remediated.  The data, while not statistically valid, suggests that an active remediation strategy increases productivity.  What we were not able to conclude was whether the cost/benefit of remediation (effort, a direct cost and delayed functionality, an opportunity cost) was positive.  The organization’s current thinking is a big “probably”.

Does aggressive or active technical debt remediation make sense?  The answer is probably not cut and dry and we certainly need more data to draw a conclusion for these two teams. In order to decide on an approach, each organization is going to have to evaluate their own context.  For example, as discussed in Technical Debt, remediating consciously accrued technical debt applications that have a very short planned life probably does not make sense. If you are dealing with a core ERP application the answer may be very different. However, if productivity is enhanced by aggressively remediating technical debt, waiting until you hit some arbitrary trigger might not make sense.