As software testers we use context to point out that not all practices may be used in any situation. This is one of the key principles of the context-driven school of testing. Robert Martin talks about particular practices in the professionals tool-belt that are used in a project based on the particular context of that project. Alistair Cockburn names the same concept Just-in-time methodology construction and defines a large amount of practices and principles to use in software development projects. For me there always seemed to be a pattern behind this concept and I decided to write it up for public discussion.
Lately, I read through the Quality Software Management series from Gerald M. Weinberg. In it, Weinberg discusses differences between the Routine organization and the Steering organization. The key difference between the two organizational cultures lies in following a prescribed way to handle a project and choosing among several techniques and practices based on the current situation. In a Routine organization there is one particular process defined and software projects shall follow this. Of course, project managers take care of following this one process. In the Steering culture there are many processes which may be followed. In a Steering culture the controller of the project chooses among several practices and knows when to adapt by taking the outputs of the previous project phases and feeding this knowledge in to the inputs of the next project phase. A controller of the project may consist of the designated project manager or the project team as a whole.
About two years back my wife amazed me with a similar lesson in a completely different area of life. For my birthday I got a jigsaw puzzle. My wife has over hundred puzzles in the house and she all finished them. When I got to know my wife, we spent several evenings together puzzling. During this period I had adapted a technique from her to get the puzzle started. By sorting out similar shapes and then combining them according to their particular shape-type, she was able to make steady progress with the jigsaws. Therefore I started by doing the same thing. Having finished the outer frame, I sorted the remaining pieces by their shape and started over.
After some hours puzzling, I realized that copying this strategy did not work out for my puzzle at hand. I did not make much progress and had become a bit fed up with it. After reflecting some minutes, I realized that I was stuck by the wrong strategy. The puzzle showed an image of penguins in an icy world. Therefore the pieces contained mostly black and white fragments of that picture. It was a lot easier to first partition the pieces according to the color rather than their shape. My wife applied the strategy by sorting out shapes with more colorful puzzle images, that helped her succeed there, but for the image at hand I had focused on the wrong strategy. After changing it I noticed that I could make much faster progress than before.
Of course, in the story above I had less experience with jigsaws than my wife had. Over the years she adapted several techniques for finishing up a jigsaw and based on the particular circumstances she choses among the several techniques she knows. When I started the jigsaw I had a vague understanding of one of her techniques and foolishly tried to apply it. Just by making myself aware of the situation when things did not turn out, I was able to try out a new approach to follow and add another technique to my repertoire. Similarly in software testing and software development we need to make ourselves aware of the particular situation in our project and reflect over the course of it. When we get aware about problems, we can help ourselves by choosing another technique or practice to follow for the next few weeks in order to improve the overall course. By continuously making ourselves aware of the situation and the context at hand, we can deal with changes circumstances and try out new things if we get lost.
2 thoughts on “On the relevance of context”
My family and I enjoy jigsaw puzzles too. One thing we all do the same way is to create the frame first. After that everyone has their own style.
I think its quite common to start using someone elses technique when learning something new. Its when we build confidence do we go on and create our own individual style and approach.
So yes, its to do with context (using the best approach for the best puzzle), but its also using a technique that suits the way your brain works. My husband and I are both engineers, yet we approach a problem in very different ways, so what works for him doesn’t necessarily work well for me.
At the end of the day as long as the puzzle is solved and satisfaction is felt, then its a good approach.
Thanks for the post
Shu-Ha-Ri is at the essence of your writing. In the shu stage you merely copy from someone, in the ha level you break free from it and incorporate the lesson in the ri stage. However, this applies to learning a single particular technique or practice. Having collected many techniques and practices, you need to know when to apply them how in your particular context. I think this is at the core of Alistair Cockburn’s Three steps of Crystal.
Thanks for your comment.