Shortcuts can get a bad rap from testers, but are they always bad?
IN 1944 the organization that would later become the CIA sent a manual to their operatives working in the underground resistance in Europe. The manual was called the Simple Sabotage Field Manual. It contained advice on how people could quietly sabotage enemy operations. Let’s see what we can learn from it.
Much of it has to do with physical equipment, but for those of us in knowledge work the section on General Interference with Organizations and Production is instructive.
Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions.
This is an interesting one for software testers to consider. Shortcuts can get a bad rap in our part of the industry. We tell people to do things the right way and to not take shortcuts in their design, development and testing.
But are all short-cuts bad? If a short-cut gets you to the desired outcome more quickly is it bad? Part of quality is consistency and some of the “channels” in our companies help keep things consistent. Sometimes shortcuts are bad, but if we never allow them, we won’t learn new and better ways to do things.
We don’t need to embrace “cowboy coding” but we can still have flexibility about how tightly we follow procedures. Part of producing good quality code is having the wisdom to know what kind of shortcuts will get you to the destination faster and which ones will leave you lost in the forest calling for help.
Don’t be the saboteur that insists that things always need to follow every detail of every procedure. Don’t just look at the piece you are working on. Look at the system and when you see a shortcut that works around inefficiencies in the system, don’t be scared to take it. Quality is as much a product of the system as it is of individual actions. Changes to the system can improve quality.
Photo by Stefan Steinbauer on Unsplash
