Why Assumptions are the Bane of Software Development
Let’s be honest, we’ve all been guilty of making an assumption only to be proved wrong later down the line. Indeed, even the great Albert Einstein noted that ‘assumptions are made and most assumptions are wrong’. However, for those of us who work in the software development industry, assumptions are a depressingly common, yet dangerous part of the job.
While some individual decisions may only cause a minor, relatively benign issue within a system if proven wrong, some developers take risks that can significantly affect the final product and can even cause major headaches for the customer they’re working for. Because of this, it is becoming increasingly essential to remain in the realm of fact-based decisions in order to minimise catastrophe.
The effects of assumptions in software development
While many decisions made during the design and development process of a product are because of the requirements made by the client, there are a surprising number of decisions made on the fly, with developers using their own personal experiences, knowledge and biases in order to move forward.
These assumptions remain implicitly undocumented and are never tracked. Yet, this doesn’t mean that they don’t resurface later down the line when the system fails or doesn’t perform as it should. Assumptions are made in a variety of development projects, yet, when they go wrong it can grow to become a significant problem.
A recent example of the inherent issues of human assumptions in the software industry can be seen in the risk assessment systems currently used by American law enforcement. Built on the inherent assumptions of the developers, the algorithm would inordinately target black people as reoffenders. While this is an especially egregious case, it is just one example of assumptions in the software sector causing serious and sometimes extremely unethical problems.
Validating your assumptions
While it is inevitable that assumptions will be made at some point during the development process, blindly using them as a solution before carrying out the necessary checks is a recipe for disaster. With this in mind, it’s essential that you validate your assumptions before enacting them in order to avert any issues.
To start with, carry out some research to find any proof that your assumption is valid or consider performing a test of your assumption in order to verify its validity. A prime example of validating an assumption is the employment of user study tests. Rather than simply assuming user interaction, a user study can instead give credence to your choices and minimise issues later down the line.
Document everything
If you run into an issue that requires some form of assumption to progress, it is vital that it is documented. As many assumptions are left out of project documentation, they can end up rearing their head later down the line if things go wrong.
A good way for software teams to document assumptions is by using the ‘risks, assumptions, issues and dependencies’ log (RAID). This can help you track any decisions that could potentially affect the product further down the line, making it especially handy for mitigating risk.
Data is your friend
Finally, it’s important to remember that we now have a wealth of data at our fingertips which can help you to avoid making blind decisions during development. With everything from system metrics to user interaction data being tracked and stored by most companies, experienced app engineers can build a valid foundation based on useful, assumption-killing data.
