The Gray Zone

When embarking on a new software project, one of the most critical decisions is that of Scope - what, exactly, is the software going to do? Even if you have unlimited budget and time, you still need to decide what you’re going to do first.

On many projects, Scope is defined by stating what is In Scope- with the implication that everything else is Out of Scope:

‘So what?’ I hear you ask? If scope was truly fixed, there would be no problem. But, scope is never permanently fixed - the best we can hope for is to nail it down for a (short) time. Why is this so? Even if the current scope is perfect - nothing forgotten or omitted - business itself changes over time due to outside forces including economic conditions, changing technology and legislation.

In the face of potential change to scope, we end up with this situation:

Essentially, by not being explicit about what it Out of Scope, we decide that every decision is reversible, and that every possibility must remain possible.

It isn’t an exaggeration to say that the effect of this on development can be profound.

In my experience, one of two things ends up happening - the system ends up over-engineered or under-engineered.

Over-engineering of the system occurs when too much effort goes into ensuring the system can adapt to future requirements.

‘We need to use a Service Oriented Architecture so that we can scale to handle thousands of simultaneous users. Yes, I know the first release is only going to have 3 users, but if we don’t design in scalability now we’ll need to throw out too much code later on.’

Under-engineering of the system can be just as big a problem.

‘We’re never going to have more than four tables in our database, so we can’t justify the time to learn a complicated product like NHibernate. We’ll just hard code our data access layer.’ Eighteen months later, ‘How many new tables are we adding in this months release? Ten? Ok, good, who’s going to code the data access layer for those?’

Fortunately, there is an easy solution. Well, easy in principle anyway:

Don’t simply state what is In Scope - state what is Out of Scope as well:

This allows your development team to make good decisions without having to make rash assumptions, and makes it clear that some decisions are only reversible at significant cost.

‘We’re not going to use a Service Oriented Architecture on this project, as we’ll never need to support more than a dozen simultaneous users. If this changes down the track, we’ll need to discard a significant portion of our infrastructure and rebuild.’

or

We need to use a proper ORM tool on this project, perhaps NHibernate. While we only have four database tables in the first release, we are expecting to substantially expand the system with a lot of new functionality over the next three years.’

The smaller you can make The Gray Zone - the more certainty there is about the future - the better for the overall project, as it allows your development team to simplify the right parts of the system, saving both budget and time.

Aside: Does anyone really have unlimited budget and time? If you think you do, I’d recommend thinking again. There are always limits.