Assumptions Were Made for Testing
Here’s another extract from my book-in-progress “The Programmers Guide To People”, the first few chapters should be available at the end of May on LeanPub. You can sign up to be notified when it is here
The Oxford Dictionary defines an assumption as: “a thing that is accepted as true or as certain to happen, without proof”. We constantly make assumptions. Sometimes we are aware of them, often we’re not.
When we attribute blame we make an assumption about the other persons behaviour, often without really knowing the reasoning behind the action they took. We make this type of assumption as a defensive behaviour rather than through any rational thought. As we have already discussed these types of assumptions damage relationships and our ability to learn from problems. Testing these assumptions is easy, we can talk to the people we are blaming, listen, and ask them about another assumptions we make when hearing their explanation. The deeper we go into our questioning the more we can scrape away the assumptions and get to the root of the problem.
When something happens we make assumptions about its cause. We can’t resist attributing simple causes to mistakes and successes when the reality is far more complex. Even when there is little evidence we prefer to make an assumption then be left with no cause. Even if our cause may be valid there may be many other factors involved that we fail to consider. We have a strong bias towards finding simple causes to complex problems and certainty because these means we don’t have to think so hard. Unfortunately simple causes can be misleading.
We make assumptions about the best way to do something. We follow others when we see them having success with a tool or method even though our context may be very different. When someone we look up to declares something to be wonderful we stick a halo on that thing and follow religiously without really testing if it will work for us. When we discover that something does work for us we like to assume that it will work equally well for others too.
We use assumptions to simplify things when the reality is too complex for us to understand. We create models with these assumptions that allow us to predict system behaviours and these work well until we forget they are only models. Our simplified models of reality must be tested continually and improved. Reality continually changes, yet we tend to stick to the same old assumptions.
We make assumptions about other people’s needs. Rather than ask or try to understand the people we are building the software for, we make guesses about their needs. This helps us develop software faster, but are we building the right thing? This question becomes even harder when we realise that our customer is also making assumptions about what they need. To discover what is really needed we must test our assumptions by allowing customers to use the software while we are building it.
We make assumptions about what other people mean when they say something. Our language is limited as is our ability to use it effectively, this results in us guessing at what the other person means. We are reluctant to clarify exactly what was meant for fear of embarrassment if we have got it wrong. In a conversation both people are making assumptions. In a meeting a large number of people are making assumptions many of which will be wrong. Much of the conflict we see in work comes from misunderstanding rather than genuine differences of opinion.
We need assumptions, but we forget that’s what they are. The problems above aren’t because we make assumptions they are caused by our unwillingness to test them. The more pressure put on us, the more assumptions we will make and the less likely we are to test them, resulting in a higher chance that the assumption is wrong. Well that’s my assumption.
What do you think? Is this inline with the way you think about assumptions? What other assumptions do we make? Should we take more time to test our assumptions?
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)