Software Assumptions – Principle source of failure
03 Jun. 2011 Software Development
Lately, as I was watching a tacky action movie, I was astonished to get a line the head baddie uttered what I consider to be one of the most significant principles of software system design. He said, “Assumption is the principle source of failure.” He repeated this captivating phrase over and over during the film. Of course, in true movie style he eventually fell victim to the very principle he was embracing all along. I believe the assumption that got him was “I have a foolproof plan and the world will be mine.” Later on when one of his own members interrogated and indicated the loophole, he stated, “I didn’t think of that.”
As with our villain, assumptions can be life-threatening to software development projects. In software organizations, we’ve seen two common patterns of software assumptions that have led to software system failure. The risk is compounded by the shared trait-the assumptions are un-verbalised.
The first kind is hidden, faux assumptions. This is where everyone assumes an entity to be true when actually it isn’t. A popular example is where a delivery organization feels that they are ready to ship the product with zero errors.
The second kind is equivocal assumptions, such as where key stakeholders make different assumptions about an authoritative issue. A prime example is where management thinks they’ve produced an early prototype and campaigning it as a complete solution is the way to go.
What software assumptions are you drawing about the software you’re developing? It is better to encourage project participants to surface and document every single software assumption, and then run off and make sure that those assumptions are both shared and true. There are some highly effective heuristic techniques, such as context-free questions, to help make the assumption track down more likely to turn up as much as possible.
Some of the context-free questions that can be asked are “What problems are we really trying to solve?” and “What problems might a highly successful solution create?” Answers to these questions can be eye-openers.
Although they aren’t especially difficult, assumption expeditions can take some organizing. Despite the effort, participants usually confess that finding just one important assumption has made spending time worthwhile.
One way to commence the tracing is to make it part of a requirements management process. It’s important that the right stakeholders participate. Another way is to involve an effective cross-sectional representing group with differing interests, such as development, marketing, QA, business analysts, manufacturing, legal, or others. The aim is to get people who will have to face the backwash of faux or equivocal assumptions in the same room to expose and analyse their assumptions together.
Once you document your set of assumptions, someone should get involved to manage those software assumptions for the rest of the project’s duration. Anticipate more software assumptions that will need to be resolved. Be prepared for the breakthrough that some of those you thought were true will, in fact, turn out to be false. If you fail to give individuals the job of managing your software assumptions, I guarantee they’ll burry back into the forest, hiding there until they become a crisis.
At which point you, like our movie villain, might be heard saying, “I didn’t think of that,” as your project is foiled.
Contact us today or call 1-877-RISHABH (1-877-747-4224) to learn more about software testing services based on software assumptions.