Refactoring

As described above refactoring, refactoring is the work required to restructure the software baseline in order to pay off the “Technical Debt.” Technical Debt can be modelled as a stock representing an accumulation of tasks over time that, once they reach a certain threshold, must be accomplished before any other development can proceed.

Figure 49 shows the APD model structure elements and feedbacks that produce this dynamic. As work in performed in the project, Technical Debt accrues at the Technical Debt Accrual Rate. Tech Debt Accrued per unit of Work represents the percentage of each completed work task that is susceptible to refactoring at a later point in time. Quantifying the Technical Debt Accrual Rate is extremely difficult; it cannot be calculated a priori, especially for a legacy program where development may occur “on top of” an existing baseline with an unknown technical debt quantity.

One way to derive a measure for technical debt is to assess the “quality” of one’s code. The SQALE (Software Quality Assessment based on Lifecycle Expectations) is one model for doing this. It is a methodology for assessing the quality of code, using algorithms to score software quality along the dimensions of: Reusability, Maintainability, Efficiency, Changeability, Reliability, and Testability. This type of analysis is available in several static analysis packages including: Insite SaaS, Sonar, SQuORE, and Mia-Quality.12 12 http://www.sqale.org/tools Some have been using the SQALE SQI (Software Quality Index) as a measure of technical debt.

Agile practitioners suggest other, simpler approaches: Agile teams can monitor the amount of refactoring compared to the amount of new feature work in each sprint or iteration to establish a historical baseline for Technical Debt Accrual.

For testing purposes of our APD model, we will measure technical debt as a fraction of the amount of correct work already performed (Release Work Done Correctly). The reasoning behind this is that Release Work Done Correctly is proportional to the size of the code base (i.e. SLOC.) It also follows that the more SLOC, the more technical debt, as it has been long established that lines of code are correlated to effort and defects, and that duplication of code is by far the most common form of technical debt.13 It’s also been highlighted by mantras in a couple of books: the DRY (don’t repeat yourself) principle in the Pragmatic Programmer (A. Hunt, and D. Thomas, Addison Wesley, 1999) and “Once and Only Once” from Extreme Programming Explained: Embrace Change (K. Beck, Addison Wesley, 1999). (Fowler, 2001)

In our model we will use a value 0.05 to represent 5 units of technical debt for every 100 correct tasks completed to drive Technical Debt Accrual. If Refactoring is practiced (using the switch Allow Refactoring) Once the Technical Debt level reaches the Technical Debt Pay Off Amount of Work, then that amount of work is moved into Planned Refactoring Work to be performed in the next sprint. Figure 50 shows the accumulation of Technical Debt over time. Once it reaches Technical Debt Pay Off Amount of Work, the stock is drained as the work is planned into the next release.