The Greyness of Gold

Steve McMcConnell's Software Project Survival Guide mentions gold plating a project, specifically: "Implement only what is required. Developers, managers, and customers often think of small, easy changes that seem to make the software better. These changes often have much more far-reaching impacts than anticipated by the specific developer who will implement the change. Do not let additional complexity creep into the project through gold-plating."

This may fly in the face of ideas like refactoring (although refactoring is generally an attempt to remove complexity not add it). To put this into context, though, the team that he's talking about is well above the quality curve: "...the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL [the team in question] would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects."

So when you have a manager talking about not wanting to have a gold plated solution check to see if your project is delivering on the 50 defects/100,000 lines of code first.

Of course, the original point is true too - you can continually seek the perfect solution to a business problem, probably forever, and in doing so add complexity to a system. Business processes aren't always rational so there may not be a good solution to the problem. So continually swapping ways of solving a problem can be an untenable situation.

I know that some people want to refactor code forever and others are happy just to write code and see if it works somehow. There's obviously a balance.

To me saying, "I don't want a gold plated solution" is asking not try to achieve a certain level of quality and certainly most IT shops should be trying to do more not less.