Gold Plating is an anti-pattern that happens when a developer continues to work on a particular task long past the point where any work on that task was useful. Alternatively, it can also mean developing features that were not originally requested by the customer.

Who let that Midas idiot in here?!

There's something to be said for pleasant-looking, easy-to-read code; I'm a fan of it myself. But there comes a point at which any more changes to a particular set of code will not make it more readable. Continuing to work long past that point is what causes this anti-pattern.  

At some point, well past the point where we should have stopped working on it, continuing to do gold plating is basically like putting makeup on a bear; no matter how much you change the outside, the inside is still a bear.  

Here, let's try it...

Apparently, Yogi does not want to look FABULOUS!

Okay, okay, sheesh.

The Rundown

What Is This Anti-Pattern?

Gold plating is one of the few anti-patterns in this series which can be considered to have two root types:  Software Design and Methodological.  

In the software design sense, gold plating is continuing to work on a software system long past the point of adding anything productive or meaningful. We've all known (or been) people who have done this: adding that last little "feature" turns into five hours of "just one more..."; spending hours making the comments look just right; taking days to locate, test, and future-proof the latest JavaScript framework so we can build a simple CRUD app.

A Kenyan programmer sits at his computer. found on Wikimedia, used under license)

In the methodological sense, gold plating is adding features which the customer did not ask for, but which are likely to impress him/her. Generally it's management or project leaders who fall victim to this type of gold-plating, which is not always a bad thing. After all, you generally want to under-promise and over-deliver in all aspects of life, not just business. Where it becomes an issue is when this mindset of "just one more little thing" causes active harm to the project, either by focusing on features while ignoring bugs, or by working on features that have little to no use.

Lucky for us, the solution to both of these problems is the same: know when to fold 'em.

Strategies to Solve

I love this adage:

"Perfect is the enemy of good."

That is exactly the solution we need when dealing with gold plating. There will always be that one little thing more. The trick is to know when "one little thing more" isn't useful anymore.

For the software design sense, this is pretty easy.  If you are writing code for your edification, rather than for the benefit of the customer, tests, or the documentation of existing code, you are most likely doing gold plating. This is not to say that you should never do this, rather that you should do it knowing what the trade-offs are. That "one little thing more" is taking away your time from other aspects of the system, like required features.  

For the methodological sense, this is much more difficult, and changes based on the person involved. Heck, it might not even be an anti-pattern at all! It could just be good business. But the thought process is the same: if you are including "features" that the customer did not ask for and won't absolutely bowl them over, you are probably gold plating.

Good enough is, well, good enough.


Gold plating is the act of adding features or code which don't contribute to the overall goal of the project; they are just there to make the project look more impressive. You don't want to put makeup on the bear; it's still a bear, let it be a bear!  

The bear necessities of life will come to you / They'll come to you

This is one of the anti-patterns that might be a good thing in certain circumstances. Did you encounter one of these? Can you tell us about it? Share in the comments! Or else head on back to the series index page to see some more anti-patterns.

Happy Coding!