front that you can't get it to me with all those other functions by the due date. Rather than waiting two or three weeks before the due date to find out.
Carol: Right. And I think one of our issues is the fact that although software is becoming more concrete and more a part of our everyday life, you can't touch and feel code. You can't tell, if a developer says yes, it will be done by a certain date, and we get two weeks up to the date, if it's a house, and you're at the framing stage two weeks before moving, you know that you're not going to move in. But with software, can you really do that?
Frank: Well, you can. Again, this gets back to fundamentals. Do you have good project estimating and good project planning and tracking mechanisms in place? So that you know how far along you are in the process. How many things you're getting done and what's likely to be done by the due date, what's likely not to be done by the due date. Do you have good metrics in place? Are you tracking historically how much software you've been able to produce in a given period of time? And applying that, going forward, to understand how much you'll be able to produce in the future. We talked a little bit about function points before. If you use the analogy of, and function points are just a rough measure of size, if you're able to produce ten function points per person-month, and your estimate on this project says you're going to produce function points at a rate of 40 per person-month, then you must ask yourself what's different about this project that I'm going to have four times better productivity than I have had before in the past? And the answer usually is, there's nothing different about this project, I've just grossly underestimated the scope and the effort.
Carol: And I want to be really optimistic, because this is going to be the project where nothing goes wrong.
Carol: And I think that's one of the fundamentals of the software process improvement, is that you need a process in place, a fundamental, structured, good process that will allow you to build in quality. And I know that you've got a favorite quote that I think you'd like to share with people about software defects. In terms of, we've got bug-laden software, and even if you use a good process, it doesn't seem like we can ever get bug-free software.
Frank: Exactly, Carol. The quote you're alluding to, which really goes back to the comment you made about this is going to be the project where nothing goes wrong, is essentially that there is no project like that. Donald Canuth, who's very well known in the computer science industry, in fact, is by many people considered to be the father of computer science, the father of computer programming, did a lot of some of the early work that turned this business from a cottage art into a more disciplined science. I'm going to paraphrase here. I heard him say one time that specifying computer software is one of the hardest things that the human race has ever tried to do. It's a very difficult thing to do. It's almost impossible to do it without introducing defects into the process. You pretty much can't specify and write defect-free code the first time. Which sort of belies a lot of the old quality sayings, "Do it right the first time" and all