and Web designers, that part of the problem is not on their side, but part of the problem is that users and customers are unrealistic or they demand levels of quality that are absolutely outrageous, that they want things to work just perfectly… And we'll come back after these messages and talk a little bit more about ……… what we can do on the user side and ………….
Hi, welcome back to Quality Plus e-Talk! I'm Carol Dekkers, I'm president of Quality Plus Technologies, which is a management consulting firm based in Florida, which specializes in quality initiatives, software metrics, process improvement, and function point analysis. My guest this evening is Frank Mazzucco of COMPASS America, who has been a developer, software manager, for the last 30 years. We've been talking about why is software not great quality. What are some of the problems, what are some of the process things? And we went into the break with the question of is it really a customer or user problem, that, do we have unrealistic expectations? Are we expecting too much from software? Is it a matter of acceptance criteria? And I'll just point that question to you, Frank. Do we have unrealistic expectations? Do we expect software to be too perfect? What are some of the issues there?
Frank: Well, thanks, Carol. I guess expectations do play into it, because of course everybody wants everything to work perfectly and cost nothing all the time. However, I think really the problem we have is more the other way around, and really lies back more on the software developers, or software development management themselves. Having been in this business for 30 years, I think we have a tendency to take on all the requirements the users give us, try to implement everything the users give us and basically we never say no. And I think there's two real reasons for that. The first reason, of course, is we're nice people and we try to please everybody all the time. And we don't even stop to think about the fact that you can't please everybody all the time. The second part of it is, we tend to say yes when a user gives us a requirement, "Yes, we can do that by September 30," "Yes, we can do that by March 1," and "Oh, we can do that other thing by March 1, too, and that third thing and that fourth thing as well," largely because we simply don't know what we can do. People who don't have a disciplined process approach, who don't have any good metrics to understand what their process capability is, what they're capable of producing in a given period of time, simply have no idea when a user comes to them, what they can do. And so they just say, yes, we can do it. Now, the problem of course with that is, as everybody who's ever developed software knows, we get close to the release date, we start to realize, well no, we're not going to able to get all 50 of those features in there by next week. So we start cutting things out and saying, okay, this is going to be the core release, which by the way happens to be whatever we've got done at the time, those happen to be the core functions. Everything else will go in in release two. Well, we really do our users a disservice by doing that. If I were a user and asked for a function to be in your software, I would much rather know up