no, we haven't and we are ready to take the risk. And even though at the beginning of the project we thought that we had to meet these criteria, we haven't. We are willing to take the risks that we are going to ship with them anyway." And then it is a business decision.
Carol: It sounds similar, to me, to kind of doing--if you were building a house, when can you have that final inspection and actually move in? And I have been on projects and been consulting to companies where release criterion was never written. It was always assumed, and so the users would always say, "Well no, no, that it is not what we meant by 'ready.'" The developers would say, "What do you mean, we have to do all these other things yet?"
Johanna: That's right.
Carol: I think that is absolutely incredibly good and down to earth advice to have release criteria that is formalized, written, and agreed to at the start of a project.
Johanna: Yes. You can even still start the project and be sort of, you know, part of the way down the road before you have them. But I strongly recommend that you at least have release criteria before the developers finish writing their code. Because if they haven't, they will do what they think is the right thing. Developers, all the developers I know have a highly developed sense of sort of integrity and moral obligation to the product. And they want to do the best job they now how. But sometimes the best job is doing a little bit very well. Sometimes the best job is putting in a whole bunch of stuff that may or may not work very well but the users are going to live with it anyway. And sometimes the best job is just making sure that you haven't screwed anything up from the last time. So, the best job is different depending on what kind of a product you have, where it is in its lifecycle, all that stuff. You need to be thinking about all that, preferably from the beginning of the project, but absolutely before you begin testing. Because if you think about it after you have been testing, you're lost.
Carol: Right. And we will be back to finalize things and sum up with Johanna Rothman after these short messages...Welcome back to Quality Plus! E-Talk. This has been a great show and Johanna and I could probably sit here and talk for hours and hours and hours, but then we would be cut off the air and nobody would be listening. We could be talking about this stuff for the next five hours easily. I would like to invite any of you that are listening who are in the San Diego area or thinking about that they would like to be in the San Diego area in February to join us for the Software Management Conference and the Applications of Software Measurement Conference--it is a dual conference--you can sign up for one and attend any of the sessions in the second one. Johanna is the chair of the software management side. I believe that you are doing a presentation there?
Johanna: Yes, actually, I am doing a panel with a few other people called, "How To Tell When Your Project Is In Trouble."
Johanna: So that should be good.
Carol: And I am doing a one-day tutorial on function points for Web-based software, and I am also doing a feature presentation called Extreme Programming Meets Measurement which brings me