We write software today, it’s important to always remember this.
Often when we are asked to write software, we are typically provided with a list of “business requirements”, constraints under which we need to build it. Some of these are architectural, some are design, some are technological, some are legal or regulatory constraints, some are business goals, and some are expected features.
Depending on the customer, these constraints have received different levels of consideration. A large established business may need a tactical solution under which many constraints are imposed (you must talk to this database, interact with this webservice, solve this problem). A new startup business may have pages full of features they want, but an intense requirement to make money as soon as possible.
The problem is, that every requirements document is incomplete. To the extent that it’s been said that the most important information in it is the author’s phone number.
One reason for this problem is that often when we write, the words we put down don’t always say to everyone what we intended at the moment they were written.
Another reason for this problem is that the requirements document was written at a time at which we knew the absolute least about the project: before it has started (see Steve McConnel’s “Cone of Uncertainty”.) Invariably and despite the best intentions and utmost upfront scrutiny, it is incomplete.
In our experience, as you begin working on a project, as stakeholders and developers accumulate knowledge about the project, you discover new information and have the opportunity to clarify many things in your original requirements.
Agile and Lean Software Development tenets tell us that if we defer the decisions we make in a project as late as possible, we can make a more informed decision simply because we know more about the project. The key is finding the “last responsible moment” – an idea championed by the Poppendiecks.
The last responsible moment is that point in time when you can make the most informed decision, and when that decision can truly no longer be deferred.
So think back to your project constraints, which of them are truly constraints and which of them are decisions made in the dark?
The idea is so insanely simple, who could possibly make a good decision without gathering as many facts as they can muster?
We should all strive to be more aware of the last responsible moment, we owe it to our customers to ensure that our projects aren’t governed by decisions made in the dark.