Just finished reading through the rumble of the year between Matt Heusser and Alan Page on code metrics. Marlena Compton seems to have facilitated the session very well, since I haven’t heard of any casualties. One striking phrase from Alan Page led me to this blog entry:
In my world, code coverage measurement is another tool in the testers toolbox. We use different “tools” depending on what we’re investigating and where we want to guide our discovery process. We always need to use the right tool in the right context.
Thus far I haven’t thought consciously about context. Alan in the above mentioned quotation made me realize that there are multiple contexts to apply context to.
Background
My initial application of context is the situation at hand on the project scale. Mostly I use the word context when I mean in fact “in the project you’re currently discussing.” By that definition this includes the context of the cultural background, the company background and the background of your customer. Since projects unfold over time in dimension unpredictable up-front, I apply the meaning of the word context to the overall time-scale of the project.
This may mean that you have a perceived rule in your company, that makes you avoid certain practices like Code Inspections or Test-driven Development. Taking a step back and reflecting over the problems people are facing you may be able to realize that more thorough unit testing might indeed help your situation. Transforming the perceived rules to guides may then help you overcome some of the most painful problems. This is application of certain practices to the situation at hand in the current project.
Situation
There is also a timely restricted meaning of the word context. Alan uses it in the citation above. Particularly, he uses the word context with the meaning of the moment. He states a component with a code coverage of 60% and another of 80%. By bringing in code coverage metrics to inspect the uncovered code fragments, he wants to make a conscious decision about the next test practice to follow. Using code coverage here is a strategical consideration. I think Alan uses the context of the moment to adapt to the situation the project calls for. Context-driven is an integral part of the strategy.
The difference
Though, it might not seem so, but I think there is a great difference between the two. The difference is similar to another difference I recently noticed. Some while ago, I wrote a blog entry on skillset development based on the Shu-Ha-Ri principle. When Alistair Cockburn described Shu-Ha-Ri to me face-to-face, I was amazed to see just this nifty difference. The Shu-Ha-Ri principle applies to learning of a distinct technique, the Practices-Principles-Values consideration of the Agile movement applies on a coarser level. Alistair pointed out that you use Shu-Ha-Ri to learn the techniques, the practices. In parallel to that you use the practices, the principles and the values to seek for improvements.
The same thing applies here. Based on the background of your project, the culture, the company and the customer, you inspect what suits well for the project, just like practices, principles and values may help in your current situation. When deciding about the next step in your project, you pick one particular practice to learn or one important test decision to take. You may use information from the code coverage system to make a better informed decision about this. The difference there is between the long-term benefits of the project based on the contextual background, and the short-term benefits of the project based on a decision I can make today. From my experience you need to take a closer look on both: the short-term benefits for the early victories, to keep the team motivated and the momentum directed forward, and you need the long-term benefits for the perspective, something to work forward to. Either alone may make you succeed, but combining them helps a lot.
