One of McConnell's 36 classic development project mistakes is gold-plating. It's also repeated in the list, so I guess the risk of falling into this particular trap is twice as high:
Jeff, nice post, came across it and referenced it in my blog post. Hope you don’t mind. My post is here
http://www.xavierpacheco.com/tech/2008/04/09/TechnologyVsDeveloperGoldPlating.aspx
Sometimes it’s fun to implement such features - just because you can, because it benefits you, because it’s different from the usual work, because it gives your software a little character, because you can do something cool maybe with very little effort/risk, and so on. I’d never heard the term gold-plating before but I’ve done it - at least, I think the following would probably qualify:
Added automatic mic cut-off to my VoIP client when pushing the noisy shift paddles on my old ACT LABS steering wheel (only when speech was not already in progress).
Added LCD display output to my email client for the LCD displays of two Roland MIDI modules, one of which I didn’t own, and the other I rarely had connected.
Added automatic continuous spinning animation of all 3D objects in the scene when pressing a key to a commercial application that really didn’t need such a feature. (But some customers found creative uses for it!)
Certainly gold-plating could easily be a mistake in some situations. But sometimes, I think it can be a bit of harmless fun and even have surprising benefits.
I guess that rule applies when ‘un-necessary’ is throughly defined.
As a Program Manager for major systems development, my approach to avoid “gold plating” or “requirements creep” is to recognize and document potential enhancements, but postpone them until a later phase, spin, increment, or delivery. Software should be done the same way. Build the basic capability, verify it works, and then add more to it.
I think that refactoring in order to satisfy a particular goal is not gold-plating whereas refactoring just to refactor is. Refactoring is a crucial part of keeping a codebase clean, but it’s not something you do unless you have a need to make the code more malleable to solve the task at hand.