e-Talk Radio: Davis, Alan, 8 March 2001


found the sweet spot to be somewhere around 20-25%.

CAROL: And we want to avoid...

ALAN: And this is of time, not of resources. Usually, your requirements effort is burning dollars at a slower rate than development, and a slower rate than testing. So, it's probably more like 6% to 7% of your total development resources, maybe a little more than that, but it's 20% to 25% of the schedule.

CAROL: Oh, okay. That makes sense. So, you wouldn't have everybody on your project team, whoever is going to be involved in coding and everything else, sitting in this massive room with every user that potentially might ever touch the system, for days on end.

ALAN: No, I would not. First of all, you probably won't have those people on board yet. If they are on board, they are working on other projects, using their expertise. You certainly want to have a few representatives from the development team on that requirements brainstorming session or requirements triage session, but not...you don't want to have the entire team there.

CAROL: Right. Now, some programmers and Steve McConnell really said this in his book on After the Gold Rush, I think it's called After the Gold Rush. He said that a lot of programmers really skip the requirements stage, and they really say, "Let's get a system into the hands of the user so that they can see what they want and what they don't want." And really the best way of programming is to code and fix. Now, he says that's the dominant way that people are programming today. What do you think about that?

ALAN: Excellent point. Let me first tell you that I agree with the position that he is taking, which is that it's good to have something in the hands of the customer as soon as possible. I differ with him on his...well, actually, I agree with him on his observation that's how we should do things today.

CAROL: Right.

ALAN: I differ in the recommendation, however.

CAROL: Oh, he didn't recommend that. What he said is that programmers feel that you should get it into the hands of the users, or customers, fast because they don't know what they need.

ALAN: Okay.

CAROL: So, he was actually saying what programmers in our society are feeling.

ALAN: Are actually feeling...


ALAN: Okay. Yes, so, I'm in 100% agreement with him then.

CAROL: Okay.

ALAN: Yes, that's what we are doing. I've actually had...it's similar to half of the people who are doing, and then the other half of people are spending too much time planning.

CAROL: Okay.

ALAN: That being the caricature of the CMM 4 and 5 company.

CAROL: Right.

ALAN: That does not mean that every CMM 4 and 5 is spending too much time planning and too much process. It's the caricature that the company is one of those. Now, my recommendation to those coders who think they should simply throw together something and get it into the hands of the customer, I happen to like that as part of the requirements process. I like the innertube prototyping cycles as part of prototyping, but I am so driven by getting, like putting quality into a real product, I don't want to put quality into my fast generations. And that's why I prefer to do the quick prototyping during requirements, and I make sure everybody knows this is only a prototype and will not become the product; it will not evolve into the product and one way of me doing that is that I

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.