Decisions In The Dark

Standard

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.

Advertisements

2 thoughts on “Decisions In The Dark

  1. Bashar AL-Jamal

    Great post covering many good points, yet concise. I think the awareness of the last responsible moment goes towards a very dear concept to me that Uncle Bob (Robert C. Martin) been talking about “Craftsmanship”. Hence I truly believe that we owe it to ourselves as Professionals that we ensure that our projects are not governed by decisions made in the dark.

    We should remember that in some cases we are not in control of all the elements of the Software we are building (end-to-end product), and therefore their requirements goes beyond our grasp. This is specially true when building enterprise integrated solutions (e.g. B2B) where the concept of having “complete” requirements is not reasonable.

    It is this Design Tension that Architecture can play a responsible role in managing it by reducing its associated risks that reduce its intended value.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s