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

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!