There's a discussion on Robert Martin's blog about whether a programmer should insist on a certain level of quality in their work. Some of the responses claim that if the client wants quality to be sacrificed, then the programmer is being unprofessional by insisting on a higher (and more costly) level of quality.
I can see their point, but I'm shocked to see that some of these posters seem to think that quality is synonymous with robustness, and that "sacrificing quality" therefore means they can skip testing. And then they're surprised to find out that the client expects the program to be bug-free! After all, didn't the client say that they could skip testing?
I'll use an architectural metaphor to illustrate what I mean:
Suppose an architect is hired to build a home, and the client says to sacrifice quality in order to keep the cost down. This does not mean that the architect can skip all the calculations involved in making sure that the building will actually stand up. All it means is that they should use cheaper materials for the unimportant parts of the building -- the eye candy, if you will.
Perhaps the interior doors are hollow instead of solid wood -- that doesn't mean that the doors don't have to open. Perhaps there's only one electrical outlet per room instead of three -- that doesn't mean that the wiring to that one outlet can be faulty.
Low-quality does not mean broken or dangerous. However it may mean ugly or tedious. So go right ahead and require that the user edit XML by hand instead of having a configuration dialog box. Feel free to leave out the splash screen with the pretty picture. But don't think that the quality of the code itself can be sacrificed without creating an extremely unhappy client, and possibly (justifiably) a lawsuit.
Followups to Sacrificing Quality:Posted on July 28, 2003 05:57 PM
More programming articles