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


a better job of requirements, we would have a higher probability up front of being something more like having a record more like the other industries than the dismal record we have currently.

CAROL: So, it's important to have requirements, to document your requirements, to document the assumptions. And it sounds like that could be really time consuming. If you have a company where you've got, you know, you're really constrained, if you look at a lot of the dot-coms today that are absolutely constrained by time-to-market considerations. And the time to market, I've talked to a number of, especially telephony companies, and when I do my classes on measurement, one of the people in one of the classes says how it is very nice to have goal question metrics; it's very nice to get the requirements down if you have the luxury. They said, "If we wait. If we are a Sprint or an MCI and we wait to get our requirements right, MCI or our competition will have the first feature out first, and even if it doesn't work right, well, they had it first and they are going to gain market share." What do you have to say for those companies that really are under Internet time constraints?

ALAN: Good question. I don't think the right answer is, if you're under the Internet time, you should not do requirements. I think if anything when you're constrained by Internet time with giving time to market, you have no choice but to make sure you do it right the first time. If you end up being close, I agree with the argument you just put forth. You're close, but you're early, you will capture market share. But if you entirely miss your market need, you will not be better off being early to market. In our company, we have around a four-month development lifecycle, in an industry which probably normally expects to have a 12-month life cycle. And where we spend a full 25% of our time doing requirements management, because from our point of view, even though we're a relatively small company and were taught strict time to market considerations, we can't afford to miss the market both from a time point of view and a functionality point of view.

CAROL: Now, is there is a balance that between the time to market that you have to get something out and it has to be kind of just good enough quality. Is there a balance between that and missing the mark? In other words, if I put something out that is, you know, kind of sort of okay and I miss the mark because it's not what people require, but I'm first to market.

ALAN: Yes.

CAROL: Will I still get the market share?

ALAN: It depends on a lot of factors. How far off do you want a mark and how poor quality you are, in all my thoughts about software, I have always considered quality to be an invariant. I don't believe you can accept lower quality in response for high functionality or having something out on market, and in the long term, poor quality will cause you to lose that market share very rapidly.

CAROL: Unless there is a monopoly situation, which is the case with most of the operating systems I use and most of the software I use. Somehow, I keep getting that abort, restart, ignore that seems to come up no matter what, and I don't have an option of going to somebody else.

ALAN: Yes. Do you really want to go

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.