Diomidis Spinellis wrote an article in IEEE Software titled "Start with the Most Difficult Part" (on his blog here, official reference here). Now seemed like a good time to apply the advice.
So I wanted to measure: What was the most difficult part. I wanted to know how many usages of the old API were present and where I should focus my efforts first.
So I wrote macker rules to detect usages to port. And I wrote a ruby script that drove the ant macker target and pulled the usage counts into a list of counts. Then I published the current counts and started a graph so we could get the usages to zero.
Here is the chart we ended up with:
This drove us to two useful behaviors:
- Getting our tests converted first, the most complex one first (exposed a lot of issues early).
- Giving our work a metrics-driven feel -- all we have to focus on is getting this to zero.
- The hardest task to port was one in which the new API didn't have anything near what we needed, and the usage measurement didn't catch that. ==> A quick pass over the tasks looking for especially risky ones (where the port would be really hard) would have exposed that earlier.
- Another team was doing other work that intersected with ours, and we were unaware of the impact of their efforts on what we were doing. ==> Being able to get their changes quickly and easily may have helped expose the problem earlier.
- Get an SVN task branch so we can integrate as a team during the sprint
- Get an SVN task branch right before merging to release and re-apply all our git patches onto that task branch so the merge is really smooth