The development team that I'm a member of has recently adapted to work according to Agile practices. This has personally highlighted the fact that I can't stop myself gold-plating code (and documentation) and I consequently exceed original estimates, when I could've delivered solutions that meet the requirements much earlier.

I think my ethic is bordering on the obsessive in that I become too attached to my code and am rarely content to release before I've refactored and perfected it to the nth degree. I am happy that I have realised this but how can I change my attitude/mentality to be content with my progress and release on-time instead?

  • 9
    Define gold-plating. To me, gold plating is adding unnecessary things (in Lean terms, producing waste such as unnecessary functionality, too much documentation or non-value adding documentation). It seems like you aren't adding things that aren't needed, but are just spending time refactoring rather than pulling down new work products.
    – Thomas Owens
    Commented Oct 6, 2012 at 16:05
  • By gold-plating I mean striving to perfect a design (perhaps to try and encourage its re-use in future) that already fulfils its requirements, not necessarily adding new functionality. Commented Oct 6, 2012 at 17:12
  • @AndyBowskill Wait with cutting out the re-use API until you have had at least three independent projects using it. You do not have enough information before then. Test Driven Development helps making the code clean. Commented Dec 27, 2022 at 21:31

4 Answers 4


The best is the enemy of good enough.

You can always do more testing, write better documentation, ferret out those corner cases, fill in what you think are missing features, make the architecture cleaner. It's never ending. However, it has to end. There are due dates that have to be met, external constraints that depend on your part of the product being finished. Striving for perfection in one small part of a product hurts the product as a whole.

  • 4
    Thanks David, that reminds me very much of a pertinent quote I read recently: "Perfect is the enemy of done". Commented Oct 6, 2012 at 17:06
  • 1
    Since the original is in French (Voltaire), it's a bit tough to say which version is "correct" -- unless one wrote it in French, that is. Commented Oct 6, 2012 at 21:51

First off, I wish more developers had this problem, not because software would end up being released later than expected but because it would likely be a higher-quality release.

If you are exceeding your own original estimates, perhaps you need to include your "gold-plating" steps as part of your estimates. If they are not your own estimates, perhaps you should be involved in formulating them.

In any case, if you have a release deadline you should stick to it. Any "gold-plating" should be left as a final step that shouldn't hold up a release. If you absolutely feel it must be included as part of a release, consider adding the "gold-plating" on your own time (i.e. outside of working hours).

What you should do is bring up your "gold-plating" steps to your team and/or management and discuss why you feel they are important. If you can convince them that these steps are beneficial, they should become part of future releases.

  • Sounds like the gold plating is not needed for the project paying the programmers wage. Commented Dec 27, 2022 at 21:32

Gold Plated Software

The first time I saw gold plating used as a description for software was in a paper by Barry Boehm where he gave the following root cause:

Gold plating. Fixed requirements specifications in advance of design tended to encourage software gold-plating. Users asked about their requirements would frequently reason, “ I don’t know if I’ll need this feature or not, but I might as well specify it just in case.”

In his description, he recommends using methods described in his research including the spiral software life-cycle model in which projects were scoped to produce a series of prototypes one per cycle, and as the spirals got bigger, a full featured product. Spiral had wide spread influence among software researchers, and was an important bridge between waterfall and Agile. A critical limitation of spiral is that each time around the spiral, cycles got longer and more expensive.

As with Agile, spiral tries to avoid gold plating by scoping more narrowly and scheduling the project deliverable long enough that teams can finish the requirements, while at the same time being short enough to permit focus on the goal from day one until delivery day. One way that Agile methods like Scrum are superior is that Scrum sprints for a time frame that does not get longer with iterations. From the paper, project management seems to have more influence on gold plating than than individual developers.

Talent for Time Boxing

Being able to time box is very important, but it is not a binary skill. You don't have it or lack it. You are better or less good with it. Whether it comes from your boss or from you, I would prefer if no one said that you can't stop gold plating. That sounds to personal, pervasive, and permanent.

A root cause analysis might help identify several issues. I am quite certain they will not all be pointing at you, and that unless you work with psychopaths, others in your team will see similar needs to improve their Agile skill set. If you know someone without problems, you don't know them very well. If you know someone who thinks they don't need to improve, they don't know themselves very well.

I hope improvements you identify will be things you can solve with your own awareness and help from the team. However, I think that is not where this ends. My expectation from the supervisor or manager who writes your reviews would be that they can also coach their subordinates to be successful. This is particularly critical when the organization is undergoing a revolutionary change like switching from planned to Agile (or ad-hoc to Agile).

Quick and Dirty or Risk Managed Prototype?

I had a manager who used to request that tasks be performed in certain way.

Quick and dirty, but a thing of beauty.

He knew the silliness of this, and it was part of his wry sense of humor. Many people say things like this and they are dead serious. Somewhere, there is a compromise or an opportunity to ease the problem with an improved technology or approach.

What can we sacrifice to fit our time box?

In chapter one of Extreme Programming Explained, second edition, Kent Beck talks about what it takes to move fast. His answer is that "you do only what you need to do to create value for the customer."


In the first edition of the same book, Beck identifies a little more closely with Boehm's views about controlling risk as being critical to his methodology by saying:

"Risk is the basic problem of software development"

In both editions, Beck lists and describes eight common risks, followed by an assertion that XP (or perhaps by extension, Agile) addresses each in a particular way. For me, most of his explanation boils down to use of smaller increments and faster iterations allows us to steer things back on course before the risks grow too big to handle.

Mentality of Sufficiency

Beck discusses resources in context of a story about the Mountain People and the Forest People and introduces a concept called the "Mentality of Sufficiency". In the context of your situation he asks "How would you do it if you had enough time?" Just this one first chapter, available as a book preview, may provide a lot of food for thought about how XP (and other Agile methods) think about constraints like time.

Compulsion Might be the Symptom, Not the Disease

Years ago I looked at a book about procrastination that stated that a lot of procrastination originates in fear. If you don't start, you don't make a mistake, and maybe you won't be criticized. Compulsion and perfectionism gives something that our moral sense tells us is better than procrastination, but probably has the same result. Consider that perhaps you are having a problem with procrastination in another form?

Criticism and Competition

In Agile methodologies like Scrum, opportunities for being criticized or punished for procrastination have never been higher. That is a vicious cycle. I procrastinate because I am criticized, I am criticized because I procrastinate. With daily scrum meetings, we are always on alert because we are always a day or less from reporting to the team what we accomplished.

In an ideal team, Scrum gives a daily opportunity to correct procrastination. Mistakes should not have time to get big before help arrives. Teams are not always where they should be trust-wise, so leaders within the team may need to proactively address either criticism or the fear of criticism to permit things to move forward.

In our world of work, each person on a team must also compete with others. It is a little bit schizophrenic to believe in having a team that shares the work and the glory for accomplishments, but then use an annual performance management process that rewards 20% of its members, punishes or expels 10% or more of the members, and pretends that the 70% majority contributes its best without incentives. I think this is a big elephant in the room WRT promoting teamwork, and to reference Kent Beck's story, it shows deep cultural ties to being Mountain People.

The Way Forward

As a member of an Agile team, it would be good to study and dialog with others about what works. If your team is using TDD to automate their unit tests with a tool, get the person who does it best to coach you. If your supervisor or manager has a problem with your documentation approach, find out what he likes or who is doing it the way he likes, and follow their approach. If it boils down to raw coding speed, investigate what it takes to code faster.

Leaders can take steps in the right direction by role modeling desired behaviors like candid talk about their own problems (not someone else's), offering and following through with help, having a dialog about how the team can move to Agile Marine style (i.e. no man left behind). Not everyone on the team has the same abilities. It may be appropriate to explore pairing team members or assigning tasks and roles that can emphasizes complementary strengths of the people involved. Planning for the growth or remediation of skills should be a rewarding part of the job both for the supervisor and the subordinate, but must happen early and often to be effective.

  • Nice, detailed answer. +1. Re "but must happen early": It's fall, so I'll use an American sports analogy. Imagine if a football team operated like a typical business with its annual employee reviews. "We're cutting your salary by 50%. You missed three easy catches in the first game, in the next four games you didn't get your game face on until the second quarter, and your running was subpar throughout the season." Once a year criticisms do more harm than good. There's no such thing as constructive criticism if it is too late in the coming. Commented Oct 7, 2012 at 15:01
  • Broken link to mountain people and forest people.
    – Wildcard
    Commented May 16, 2017 at 4:21

I've also been annoyed with restrictions at work that take the fun out of programming, and to compensate I'll sometimes fire up a new project at home and "do it right". The split allows me to satisfy both: my needs and the company's.

Or, you could develop a new skill other than programming to do in your off time that (eventually) satisfies what the job can't provide.

  • Welcome and thank for making your first post on Stack Exchange Programmers. Please consider entering follow up questions as comments to the question rather than as an answer. You can learn more about the criteria for writing high rated questions and answers, and gain a badge by reading the faq at programmers.stackexchange.com/faq Commented Oct 7, 2012 at 2:40
  • Thanks duanev, your first paragraph definitely rings true with me too! Commented Oct 14, 2012 at 18:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.