I took stock of the year’s progress on one of the projects that I monitor for technical debt. The 70 developers were under considerable pressure to sidestep writing unit tests for all the lines and branches they added. The team was adding code at a rate 40% higher than last year. Furthermore, Sonar wasn’t fully functioning for the dot Net part for most of the year.
However, at the end of the year, 45% of the developers had no debt. This means that they covered all branches and lines and added no static violations (PMD, CheckStyle and FindBugs). Most also increased the quality of the programs in addition to avoiding debt.
So, although not TDD, at least no technical debt for nearly half even under project pressure. Admittedly, many paid back the debt after code release but at least the debt was paid back. The rest will be paying back the debt early this year.
One assertion I hear, especially from managers, is that when the work volume increases, the commit error rate increases. By commit error, I mean a source code commit that has some form of technical debt, be it an uncovered line/branch, static code violation, duplicated code, tangle or exceeding a complexity metrics threshold.
So I plotted monthly velocity (file commits) on the vertical axis and the corresponding monthly commit success rate on the horizontal axis. For a 2-million line Java over 50 months I plotted a linear regression line on the XY plot.
What were the results? Absolutely no correlation. One the busiest months had the best quality rate and one had the worst.
This jives with my experience. I’ve often seen the busiest teams with the tightest deadlines still deliver debt-free projects. They have a constant focus on their technical debt and strive to commit code with no Eclipse yellow warnings and all green code coverage. On the other hand some teams seem to ignore quality figuring no one seems to care.