Based on my observations and experience, I believe the following to be the business case for paying down Tecnical Debt.
- The acronym "DRY" stands for Don't Repeat Yourself.
- Code Coverage means the lines of code exercised by automated tests.
DRY code yields full percentage gains in productivity.
If you have 100% duplicated code and clean it up to 0% (purely hypothetical) then your productivity improves by the same 100%. In other words, what took a team of 8 now takes a team of 4 because the amount of code to wade through is half. If your team did 16 points per sprint, they can now do 32.
Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * (1 - DUPLICATION)
Example: Team currently does 20 points, has 30% duplicate code. Their maximum productivity is...
20 = MP * .7
MP = 20 / .7 = 28 points
This means the team could work on lowering duplication from 30% to 0% to bring up their productivity from 20 to 28. Now size what kind of effort that would take to reduce duplication in order to make the right business decision.
Code Coverage yields half percentage gains in productivity.
If you have 0% Code Coverage and write unit tests so that it reaches 100% (purely hypothetical) then your productivity improves by 50%. This is due to the fact that while unit tests reduce defects and rework, it creates more code to maintain. In other words, what took a team of 8 now takes 6 because you can modify code, refactor safely, and add tests more easily. If your team did 16 points per sprint, they can now do 24.
Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * .5 * (1 + CODE_COVERAGE)
Example: Team currently does 20 points, has 30% code coverage. Their maximum productivity is...
20 = MP * .5 * (1 + .3)
MP = 20 / .65 = 30 points
This means the team could work on increasing code coverage from 30% to 100% to bring up their productivity from 20 to 30. Now size the effort it would take to write that many unit tests in order to make the right business decision.
Please let me know your thoughts.
.
This is interesting, thought provoking set of formulae. A few thoughts:
ReplyDelete- 100% code coverage, this should not be the goal, right? It may be a side effect of TDD when Test cases are written first. For after the fact unit testing is that the goal?
- This technique puts focus on improving the unit testing after the fact. Care would need to be taken to promote TDD and get the team off of the after the fact testing treadmill. That may skew the numbers.
- Assumption is that the team knows unit testing, mocking etc. The Learning curve needs to be factored in, specially if it comes down to JS unit tests.
- If the velocity of the team changes each sprint such that the average is a moving number the MP would keep changing.
Just a few cents.
There are still a few more thoughts rumbling in my head, need to sort them out before I write.
Good thoughts.
ReplyDeleteI updated to be a Hypothesis, rather than a Theory since this is not proven, just an observation. Also, I recognoze the scenarios of 0% duplicate code and 100% code coverage are unattainable, rather seemed like simple endpoints to test the hypothesis.
This does not take into consideration the time it would take to learn unit testing, rather calls into light the BENEFIT of if you could get there. It's up to the team to decide COST to getting there and whether it's worth it is up to the business.
The velocity of the team will change, and this calculation would need re-run as the delta or BENEFIT you could achieve goes down, if your velocity is increasing.
Thanks!