Assumptions: the bane of manufacturing software development

However, for those of us who work in software development for the manufacturing industry, assumptions are still a depressingly common – and often dangerous – sight.

Some assumption-based decisions may only cause minor, relatively benign issues within a system if proven wrong. But some developers take risks that can significantly affect the final product – and cause major headaches for the manufacturer they’re working for.

Because of this, it’s becoming increasingly essential to remember the need to remain firmly in the realm of fact-based development decisions. Otherwise, you risk eventual catastrophe.The effects of assumptions in software development

Many decisions made during the design and development process of a product are due to client requirements. But a surprising number of decisions are made on the fly – developers using their own personal experiences, knowledge, and biases to move forward.

These assumptions remain implicitly undocumented and are never tracked. They only surface later, when the system fails or doesn’t perform as it should. Some recent examples of this include:

1. Toyota “ghost” acceleration – several years ago, a spate of car crashes were caused by Toyota vehicle software that disabled safety features and created all sorts of other issues. Millions of vehicles had to be recalled. Toyota’s stock price dropped by 20%.
2. Nest leaves people cold – due to a firmware update fault, the Google-owned smart thermostat Nest started draining its own batteries. The issue was due to older, incompatible boilers and air filters and was fixed with a later update.
3. Interlogix panic alarms don’t sound – this manufacturer of personal panic devices had to recall nearly 70 000 products because they didn’t actually sound during emergencies. The company handled the issue generously. But the cost was steep.

All of these issues were caused by assumptions made during the software development process. Assumptions that – with the right user research and data at hand – would never have been made.

How to avoid making assumptions

1) VALIDATE
It is almost inevitable that assumptions will be made at some point during the development process. But blindly using them as a solution before carrying out the necessary checks is a recipe for disaster.

With this in mind, assumptions must be validated before they’re enacted if you want to avert later issues. Research is key. You need to find proof that your assumption is valid or consider performing a test of your assumption.

A prime example of validating an assumption is a user study test. Rather than simply assuming user interaction as the companies above did, a user study can instead give credence to your choices and minimise issues later down the line.

2) 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 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 later, making it especially handy for mitigating risk.

3) DATA IS YOUR FRIEND
Finally, it’s important to remember that we now have a wealth of data at our fingertips that can help avoid blind decisions during development.

Everything from system metrics to user interaction data is now tracked and stored by most companies. This means experienced app engineers can build a valid foundation based on useful, assumption-killing data.