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:

Everything is in might be in 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:

Everything is in might be in scope

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:

Some is definitely in, some is definiately out

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.’


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.


blog comments powered by Disqus
Next Post
Future Trends  07 May 2008
Prior Post
Spec#  30 Apr 2008
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
May 2008