Test the quality of your assumptions as you analyze, design, code, test and deploy/ship your next app.

As you prepare to tackle a new project, you probably make sure all the proverbial IT ducks are in a row.  From skills sets, tools in both hardware and software, environments, connections... the list seems endless at times.  You always make sure to acquire the highest quality of tools and skill sets that your budget can buy. Have you ever considered to inspect the value or the quality of your assumptions as you step into a new project? Failure to keep assumptions in check may lead us to have faith in pursuing a goal of oversimplification, or worse, believing in a myth!


What you assume or assumptions you fail to verify can have a significant impact on the quality of the overall solution you are delivering. In the business of Software Engineering, it is not easy to divest ourselves from assumptions. Some times, that is all we have at the beginning of a project, no matter how big/small. That level of risk is probably acceptable as we try to get a software project up and running, but it must not be the end of our quest for improving the quality of our assumptions.

Based on the work done by Magne Jørgensen, what follows are examples of assumptions that tend to cloud our judgement, especially when we are under pressure to deliver high quality software, cheaply and in the shortest amount of time possible.

• Most Communication Is Non Verbal
• Brook's Law: "Adding man power to a late software project makes it later."
• 45% of software features are never used
• Factor of 10x increase of error correction in SDLC phases
• Productivity ratio of 1:10
• Non-Falsifiable Claims

All of these have their own interesting considerations, perhaps worth their own post. However, we'll only concentrate on the last one for the rest of this one: Non-Falsifiable Claims. These are the statements that you may hear from a project stakeholder where they offer a statement that may seem true. How do you handle such statements? Do you accept them? Do you challenge them? How do you challenge them?  Jørgensen suggests several reasons why myths and oversimplifications (like the ones listed above) occur, among them:

• Confirmation bias: "We see it, when we believe it"
• Poor studies
• Misunderstood or over-generalized research results
• Usefulness bias: when any claim supports our belief we tend not to corroborate its validity
• Insufficient check of the validity of a claim
• Desire for simple formulas to solve a problem (deterministic relationship)
• Belief in authority
• Repetition: the more frequent a claim is repeated, the more we believe it

Fortunately for us, there are ways to combat these problems and ensure we are self-aware of the quality of the assumptions we make. According to Jørgensen here are some tools we can use to improve the quality of our assumptions: 

• Understand the meaning of the claim or assumption. What does it really mean? Is it possible that the assumption is false?
• Think about what kind of evidence you would need to find in order to confirm an assumption. When you do, look for such evidence.
• Do you have a preexisting bias towards the assumption?
• Is the assumption based on a statement from an influential stakeholder?
• What is the quality of the evidence that supports the assumption? Who collected it? What was their motivation for it? Is there any evidence at all that supports the assumption?
• What does the full body of evidence about the assumption say? How strong is it? If the context of the assumption changes does it still hold true?

As you continue to improve the quality of your IT projects, make sure you keep front and center the level of quality of the assumptions you or the stakeholders make. Learn to check them and reconfirm them as often as possible.

Source:

Jørgensen, Magne. 2012. MS. Simula Research Laboratory, Oslo, Norway. Myths and Oversimplification in Software Engineering. Simula Research Labs, 15 Aug. 2012. Web. 17 Nov. 2013.