The Artima Developer Community
Sponsored Link

Good Enough Software
A Conversation with Andy Hunt and Dave Thomas, Part III
by Bill Venners
March 17, 2003

<<  Page 2 of 3  >>


Specifying Quality as a Requirement

Bill Venners: You also say in your book, "The quality of the system you produce should be specified as part of the system requirements." Why is that?

Dave Thomas: You say to a user, "You can have this software in two months. We anticipate it will be perfectly usable, though it may have a few rough edges. Or, we can polish it to perfection, and you can have it in seven years. Which would you prefer?" I think the user should get to make that choice. As a result, it is actually a part of the user's requirements to say what level of quality they want delivered.

Andy Hunt: And that's not an easy question. In the space shuttle, for instance, the correct answer probably is seven years. In the commercial sector it probably isn't.

Knowing When to Stop

Bill Venners: You say, "Don't spoil a perfectly good program by over-embellishment and over-refinement." How do I know when to stop?

Dave Thomas: Fundamentally, you know when to stop when the user says stop. One of the mistakes that a lot of developers seem to make is to develop in a vacuum. They'll have a project plan that says nine months from now we'll deliver something. Nine months later—or two years, whatever it ends up being—they deliver something and assume the project's gone away. But that approach is never going to work effectively.

If you work with the user more closely, if you work interactively with the user on a daily or weekly basis, then that user's going to be able to tell you when it's time to stop. You don't let the programmers keep adding features simply because they feel like it would be a good idea. Adding features should be a user decision, not a programmer decision.

Andy Hunt: In fact you can get the problem both ways. Sometimes programmers will want to keep piling features on after the program's done, but more often I think you get the opposite problem. Once the programmers have done most of what the user wants, they stop. They stop too early, when the program doesn't necessarily meet the user's needs. You can stop too early, or too late. And in both cases, the answer is feedback. As Dave said, if you work very closely with the user, you've got a much better way of judging if you're done yet.

<<  Page 2 of 3  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use