The Pesticide Paradox - the blend between Software Testing and Agriculture

The understanding of fundamental principles in a discipline may come from the most unexpected areas in the most unexpected moments. It is all about learning at every step about everything around you. Such an example is the Pesticide Paradox in Software Testing. I learned it 12 years ago from a BCS instructor, really understood it three years ago while meditating in my organic farm, remembered it a few days ago at the same farm, put in practice again today in a major IT project for the benefit of my customer.

Have you heard of this principle? I am sure most of you have heard of it but, who is putting it in practice? There is a slight gap between theory and practice, lots of things sound nice in theory but when it comes to putting them in practice there is a resistance from people.... that's until YOU FEEL IT! My Tai Chi master usually tells me to bring the principles to the muscles.

What about Pesticide Paradox? Well, it was discovered almost 20 years ago by Boris Beizer who stated that “Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual.

That’s not too bad, you say, because at least the software gets better and better. Not quite! "

It struck me 3 years ago when I had a massive attack of phytophthora infestans  in my tomato crop (one of most often encountered disease in my region). Since I was a greenhorn in agriculture and I asked the advice of professionals in the field. I am talking about organic farming, that makes the challenge even bigger because I must use only ecological solutions. After some time I came up with a recipe that worked for most of the plants... That was in the month of June (the beginning of high temperatures). I thought I was the master of Software Testing... oops sorry :) organic agriculture but, that lasted until August - September when humidity raised, the fungus appeared again in an even more ravaging attack. Same solution "mechanically" applied had a much lower result, I applied again, and again, the software seemed to get better and better but not quite! My plants were still sick and production was decreasing. Why? why was it not working with the same efficiency as the first time? It was at that moment that I had to step back, breathe deep and use my brain to find a creative solution. How was my context different from the first time? At first the heat and humidity were different than in June, I was at the second release (second series of fruits were ripening) the plants were affected by high heats in August and touched by humidity. Different conditions in my software (even if apparently much hadn’t changed) I had to ask the farmer to change his treatments and what I did was to increase the percentage of garlic in my five elements formula (doubled it) and results started showing, the plants were revigorated. It seems that the method I used before left a residue of subtler bugs (fungus) against which the same method was inefficient.

Who should use it? Well you might be tempted to say "the farmer should ..." but I would say this is for all you software testers that need to change constantly the testing techniques you use, to vary the proportion of your main "ingredients" and flush the bugs out of their hide outs. I strongly believe that our brains must be used for creation of new solutions, feel free to innovate based on the existing principles. Let the machines do the execution. This morning, meaning one hour ago, I just asked my team to enhance the input data of our automated testing performed on the current project. More data means more paths covered through the application which means more bugs found. 

Why put it in practice? If it is not obvious yet I lost about 30% of my crop (a few hundred kilos) while stumbling in the application of the same solution... you do not want to let bugs escape in production where they are more expensive to fix.

How I put it in practice in IT Projects depends on the context of the project, in most cases I rely on automated testing, the machines should do the repetitive work, and in this formula I play with one of the five ingredients: variation of input data, increase the number of checkpoints, apply testing techniques to cover more situations, increase the frequency of tests, or increase the duration of tests (did I tell you that automated tests can be run overnight? ... If not I surely will)

What can you obtain if you apply this principle correctly? A very low proportion of defects in production or better said lower costs...   

Success and remember to innovate!