What are you assuming? Every software development project contains many assumptions. Often, they’re obvious things like “the software has to operate in Windows 7 using IE 9 or above”. Yet at times, they’re not quite so obvious like “the software has to be written in Java”.
The problem with assumptions is simply that they are rarely written down and discussed. Everyone just takes them for granted. Here are some things that business people might assume:
- We know exactly what we want.
- The basic software structures have been around a long time and can’t be changed.
- The software team is fully up to date on the newest technologies we might need.
These particular assumptions may be valid in some situations but my experience suggests that assumptions like these are often wrong. Yet, business people aren’t the only ones making assumptions. Here are some that the software developers might make:
- The business knows what it needs.
- We can’t change long-standing business process paradigms.
- We have to use currently established software tools and technologies.
Assumptions are devious. They can suck the life out of software projects. Assumptions like those above build a virtual wall around the solution space. Viable options are discarded without proper due diligence because they violate an implied assumption. Our thinking is constrained and so are the solutions we devise.
A True Story
I recently had business users and managers send me new requirements for enhancements to an existing enterprise application. The requirements seemed a bit odd and convoluted to me so I challenged them to explain what they were trying to do and why.
It became apparent that were trying to fit a new workflow into the existing software paradigm. They believed that new work items had to fit within the existing software framework. They were also trying to minimize the amount of software development needed.
In the end, they were actually creating more work both for themselves and for the developers because they were making invalid assumptions. It’s often assumptions or “unspoken requirements” that cause major problems for software developers and business people.
What assumptions has your team made? Get them out in the open where they can be discussed and confirmed. Don’t solve the wrong problem because you made a wrong assumption.