Requirements

It always strikes me as interesting that we build software systems/products with no idea of what we're building. Then, we ask "How long is it going to take?"

C'mon.

I want you to build me a house. How long is it going to take?

If you answer that without asking a few basic questions, you don't even deserve the title of village idiot. How many bedrooms? How many bathrooms? Where is it going to be built? What kind of soil is it going to be built on? (OK, I'm from California. That's important here, or you find your house at the bottom of a cliff. Midwesterners, please feel free to ignore that last one.) Do you want the formica cabinet tops? Or, the Italian Marble? Pool? How big?

Remember, the Hearst Mansion (known as Hearst Castle) was just a house to someone.

Or, did you just mean a two room bungalow for you and your daughter?

Wallboard vs. lath and plaster. Formica vs. marble. 6 rooms vs. 30 rooms. It all makes a difference.

So, why are we so willing to start building software without any CLUE as to what is it we're building? I don't know, for sure. But, I think I know. The answer is: They don't want to know. That's right. They don't want to know. "Why?" you ask? There are two reasons.

First, accurately describing what you're building takes time. And, most software development projects don't have time to define what they're building - they just need to get started building it, whatever it is... Furthermore, if you write down what it is you're building, you run the risk of someone disagreeing with you. So, this means that you need to go through a "consensus building" process. Either that, or you ram it down their throats, and that has been known to piss people off. Now, the bad news is that consensus building takes time. Lots of time. Hey, it's a software project, remember? We don't have lots of time. OK, so the easiest way out of this is to just ignore the requirements altogether. That way, until the very end, we think we're building what they want, and they think they're getting what they want. Once it's delivered, we can claim that we've delivered it, and if anyone else claims that it doesn't meet the requirements, we can always say "What requirements? It's a house! Barbie and Ken can live in it! What's wrong with you?"

The second reason no one gathers requirements is that they would suddenly realize that it took WAY more time to build the product then they had been allocated and this would mean that they should either find new jobs or find a reliable source of Vodka.

Now, in case you've only been paying minimal attention to this point, here's a short quiz...

1. How can you tell how long it's going to take to build it, or whether you're on schedule if you don't know what you're building? (this is multiple guess - go ahead, it's not that hard!)

a. You can't.

b. You can't

c. You can't

d. You can't

Right answer!! You can't!! You have NO CLUE!!

So, if you don't know how long it's going to take, or what you're going to have when you're done... what do you do? First, you need to find some relief.

Now, there's a question we've ignored up until now. We've covered the fact that no one really wants to know. Now, there are a couple of additional questions that seem worthwhile.

1. Do you really want to know? If not, there's nothing I can say that will help you. You can add your schedule to this list.

2. Does anyone around you really want to know? If not, there's nothing I can say that will help you. You might spend your evenings and weekends here...

Of course, the real problem if you don't know what you're building is that you don't know what you'll get when you're done.

(more to come on this particular rant!!)

Home

Previous Articles

Three Kinds of Engineers

Only Half Full

Taking a Sit

Making Decisions with Less Data

Temporal nature of success

Being overqualified

Defining what you're building

The real problem

Origins of the name