Sylvia is a very good cook. She makes a particularly fine roast ham, using a family recipe that begins, unusually, by cutting a section off both ends of the meat. One day, a friend dropped by while she was preparing the dish. “Why are you doing that?” he asked, as Sylvia carefully trimmed that ham, “Because that’s the way my mother always does it,” said Sylvia. But it got her wondering – why did her mother start that way?
A few days later Sylvia was at her mother’s house. “When you make that special ham, why do you start by chopping the ends off the meat?” she asked. “Because that’s the way my mother taught me,” came the response. Sylvia knew she had to get to the bottom of this. She picked up the phone and called her grandma. “Tell me Gran, when you used to make your roast ham, why did you always start by cutting the ends of?” The old woman paused for a moment in recollection. “Because I didn’t have a big enough pan,” she replied.
I’ve been thinking a lot about Methodologies lately, and the above story from New Scientist magazine (April 1st, 2006) makes the point perfectly that blindly following a process creates cases where you end up doing things that make no sense in a different situation.
Software pundit Joel Spolsky seems to discount the idea of having a Methodology at all – it can be replaced with a quality team of talented people with solid experience. But experience is a dear teacher; giving talented people something that will give them a framework and help them avoid the non-obvious traps has to have some sort of value, right?
Just about every methodology document I have read focuses very heavily on what to do. First you do step A, then step B, if condition C happens, then do step D. This prescriptive format is great if every project you do is exactly the same, but as soon as you encounter something different, you are cast adrift – doing things that make no sense, and groping your way through processes you have had to invent yourself to cover the gaps.
Because most Methodology documents usually seem to be written with one project in mind, they don’t generally bother outlining why the different activities are necessary – it’s probably considered pretty obvious when you only have a single project as an example. But if you explain the why, any halfway bright person can usually figure out the how for themselves. And, it’s harder to fall into the trap of rigidly following a process when it is clear which parts of the process are relevant to your situation.
My current feeling is that the core parts of a performance testing Methodology should fit on a few pages, and be built around some simple key principles like “find problems early” and “demonstrate value” (especially important for a consultancy company). Obviously there will be a need for supporting documents like templates and technical notes, but if it not possible to read through the core process in less than 10 minutes, then something is wrong.
I will let you know how my theories stand up to reality as I do more work in this area, but if anyone out there has any feedback or experiences they would like to share, it would be greatly appreciated.
Related Posts
3 Comments
Comments are closed.
I have found a powerful tool to use in resolving the skill vs. process debate: heuristics.
A heuristic is a fallible method of solving a problem. For instance, a hammer in the hands of a carpenter is a heuristic device. The hammer doesn’t guarantee a solution to any particular problem, but it can be used to solve some problems, if used skillfully.
Heuristics bring structure to skill, help us manage our reflex behavior, and thus they point the way to resolving the concern many people have about relying on skilled heroes alone. Look at any process document for performing an intellectual process, and what you see is a heuristic. The terrible problem with most process documents, however, is that they enthrone their heuristics. This is the big mistake. Instead, place skilled practitioners in charge and *support* them with heuristics. Train them in the responsible use of heuristics.
So, the true process for cooking a roast is (among other things) to bring the roast into contact with sufficient heat for a sufficient period of time, such that the necessary chemical reactions take place. A skilled cook knows many alternative ways to do this. One way is to place the roast in a pan in an oven. If it doesn’t fit in the oven or in the pan, consider resizing the roast (that’s a heuristic). By failing to distinguish between skills, heuristics, and mere actions, the ability to cook was diminished in that family.
Good process = skills + heuristics
– James
Great story about the ham. I’d say give the team of talented people the methodology itself — the toolkit of things you could do on a project — not the process already culled from that, as you point out, probably for some other project in the past. But my comment implies the need for the whys of things, as you continued to point out.
In short, I agree! Thanks for this post!
There is a very insightful paragraph in a review of Peopleware that says:
Following that was a signifigant discourse on Methodology (capital M), it was interesting to see comments made about how blindly following the Methodology is often a more effective way for workers to get what they want from management as opposed to a strike or stop work action.