Your Assumptions Are Probably Wrong

To give this post some back story. For my day job, I work for software companies. Over the years, team members have moved on and new team members have joined. When we talk about the software and perform our software planning tasks, there tends to be a lot of assumptions. This is something I have been noticing over the years.

Assumption: an assuming that something is true


Fact: something that has actual existence

You know what they say when you assume: "You might make an 'ass' out of 'u' and 'me'". When it comes to software planning and assumptions I will say "You are probably wrong". Of course this is contextual to the software and the team working on it. The older the software and the less experience the team, the more assumptions will be incorrect. I have found it is best to avoid assumptions in software planning. When you know something it's fact, but when you don't know, you tend to assume.

A lot of this is the nature of software and it's complexity. The more complex the software, the more it plays a role in the assumptions of how it works, instead of knowing. Complexity could be on the code level which only the programmers have to navigate. Software complexity can be a user level with an overwhelming amount of features bolted into the product. Assumptions grow from complexity and the uncertainty of how it works.

History or a lack of, can also be a source of assumptions. It is easy to blame the past for a reason today. The lack of history can lead to a lot of questions and confusion. What was easy in the past might not be today and vice-versa. Having documented software history is better than having none at all. It's best to not rely on historical metrics for tomorrows goals.

To prevent making assumptions in software planning, we can investigate, test and document. It's easy to make assumptions how the software will work. It may have worked that way in the past or other parts of the software work that way, but those are assumptions. To turn our assumptions to facts, we need to investigate and test. This means we need to read or use the software to prove that our assumed idea is true. Once we have verified our assumptions it will be a good idea to lightly document that understanding.

So when it comes to software planning do not base it off of assumptions. Either bring facts to the planning table or create some tasks to investigate any assumptions. This understanding will improve everyone's knowledge of the software on the team while also keeping plans based on facts. It's no fun for anyone when a project starts and assumptions are wrong and you have to start over.