as a result, the quality that they produce, the productivity of those groups, can be very, very low. But smart people have started to realize that if you improve… that the only real way to improve the process, the quality of the software, is to improve the process by which you build it. So you're starting to see, not just smart companies out there improving these processes, but you're also starting to see some standard frameworks that are being put in place to help people improve their processes. I guess a good example of this would be the Capability Maturity Model for software, which was developed by the Software Engineering Institute at Carnegie Mellon University, which is a good framework for helping you understand what things need to improve and sort of what order you need to go about attacking them.
Carol: Right. For anybody that's listening, that doesn't necessarily know how software's developed, umm, it basically starts with somebody sitting down with a programmer, I guess, traditionally, and saying, "I want a system" or "I want a laptop or something that will do certain things for me." Correct?
Carol: And then from there, once… that formulates the requirements essentially. And that's basically the way people start, isn't it?
Frank: That's exactly right. And what you'll see, though, is because the process of understanding requirements… Requirements are typically specified, of course, by nontechnical people, or specified by the business people who want to use the software, they're specified in English language, often in very fuzzy terms that "I want a system that will do such and such." By the time that those requirements get translated into the very precise programming languages and other definitions that are required for that to run on a computer, there's been so many translations and so many interpretations of what's happened that it's often like that old party game of starting at one end of the line and whispering in people's ears, and passing the saying along to the end, until you get down to the end and you've got gobbledygook that's nothing like when you started.
Carol: Right. And I think when you introduce the fact that a lot of companies don't follow a standard process… If we take the party game, the password party game as an example, and I say, "I want a system that will allow me to create customers, or create invoices," as an example. And then you decide that you're going to pass it to the next person, but you're going to write it down, and the next person says, "I'm not going to write it down, I'm going to whisper that." And the following person says, "No, no, no. I'm going to dance it." And the next time you go through the process, I think what you're telling me is that it's not standard, that we don't follow the same process from start to finish and that causes some problems.
Frank: That's correct, because first of all, if you don't follow the same process, then when people start a new project like that, they've got no idea what to do. Because they have to figure out, "Okay, how are we going to do it this time?" Like you said, last time we whispered it, this time we're going to dance it, or this time we're going to write it down. So you don't have that basic framework in place. And second, because you don't have that basic framework in place, you don't get any level of consistency. And that leads to poor quality, it leads to