In Musashi’s time, this principle, the final one in his Way of Strategy, was exhorting his pupils to fill each shining hour with valuable, objective-oriented activity. Practice, train, do – that was the mantra. Our modern age might encourage us to add: learn, create, teach, share.
But much of our corporate life might be taken up with meaningless activity. No matter how streamlined and agile our teams may be, we may find ourselves working with partner companies whose ideas don’t match our own. In a recent testers’ meetup, I heard an account of working with a digitial media partner whose internal compliance criteria required the submission for scrutiny of all the content provider’s test cases and scripts. Their reaction was, shall we say, interesting.
But most of our thinking has gone beyond this. “Do nothing that is of no use” could equally well apply to our working practices. We should look for ways of working that eliminate pointless activity and add as much value to our products or processes as possible. If there is one thing I took away from thirty years’ working in the UK Civil Service, it was that there are actually good reasons for a lot of bureaucracy; but over time, these get forgotten; then new managements bring in “reform” and “sweeping away the cobwebs”, and this works reasonably well until suddenly one morning, people wake up and things have all gone horribly wrong. And then we find ourselves hastily re-inventing the bureaucratic wheel. I’m going to be a bit heretical here; it’s my opinion that the public sector, having been under continual political pressure to “cut out pointless bureaucracy”, has actually got rather good at streamlining processes to get the maximum benefit for the least effort (at least in areas where political interference is kept to a minimum). The worst bureaucracies are to be found, in my opinion, in the supposedly efficient private sector, especially in finance and insurance.
These latter two sectors are good examples of complex organisations. And it is those organisations that severely test our ability to “do nothing that is of no use”. But the more complex a system is, the more likely it is to demonstrate situations where there are unexpected system behaviours and outcomes.
James Christie has written a series of blog posts on the subject of “The dragons of the unknown”, about the broader testing issues exposed in a career that started out working for one of the major corporate accountancy firms and then moving into business audit work before specialising in IT audit, which is rather like software testing but coming to systems that are already in place and at a time when they aren’t actually broken (well, at least not in the eyes of their admins…)
In the second blog, he looks at the characteristics of complex systems:
And he writes about the nature of IT audit work in the final post of the sequence:
All this goes to show that there is value even in the most menial of tasks if you can extract lessons from it that you might be able to apply elsewhere. I wrote in earlier posts about the value of experience; well, this is the “information gathering” phase, where to get the experience to inform your later decisions, you first have to put the time in at the workface. Experience cannot be bought, only taught.
There is a story that if you asked someone sweeping up leaves outside NASA’s Manned Spaceflight Center in Houston what they did, they would say “I help launch the Space Shuttle”. That is an example of knowing about the whole organisation’s objectives and how an individual fits into the wider system. It also suggests an appreciation of the interconnectedness of things, which again is something that the modern world relies on. An appreciation of the relationships within complex systems will help show areas where tests are in or out of scope, because of interactions with a different app, or an upstream or downstream system, or an external provider, or a third-party application. There will be points of hand-off between all these, and criteria for successful hand-off. Often, in complex sytstems, these are the points where failures can occur. James Christie writes about not relying on the system specifications as Holy Writ to be adhered to, but such documentation can reveal where someone overlooked some data packet parameters when designing a downstream application. At some point, a tester may well have to report that what looks like a bug may be a configuration issue, or a problem in another application; and the fix may not be an IT matter but a business decision.
Very few of our systems work in complete isolation. And the more everything is connected to everything else, the more likely it is that the solution to a problem might lie outside the immediate environment. And that is where we might find that nothing we ever learn about the real world is ever “of no use”. Even in a 16th century manual of strategy for samurai.