Gold Plating: When Less is More

Do people gold plate anymore or do they just expand the scope to include new features and functions? You know what “gold plate” is don’t you? It’s a general term that usually means adding more to the system than specified in the requirements.

I’m always amused when I hear, “It didn’t take much time.” “It works better this way,” or “I needed to do this to make the other requirement work.” It can seem like some folks are just adding on, but it can become “gold plating.”

What most people don’t realize is that unnecessary additions, that shiny gold plate, can impact the effort.

Additions can indicate a problem with the maintenance and control of the actual project. One would wonder who’s managing the project and making sure there are no negative impacts, or false positive ones.

That gold has a cost. It can increase the maintenance depending on the type of gold plating done, but it can also reduce quality by taking appropriate time away from scope that has yet to be completed and causing team members to take shortcuts.

Here are a few reasons why we succumb to the shine.

1) We can get fascinated by new technologies and want to try them out. We don’t always know if they can deliver, but boy do we want to try slick new things.

2) Making some assumptions regarding the stated requirements and creating more than asked for which is often a personal opinion or gain item

3) Some would even say that refactoring code could be considered gold plating but it’s a fine line. I would say that it is, unless it’s considered part of the functional and technical requirements scope document.

How to stop yourself from gilding the lily.

1) Know your scope. As the PM, you should know the scope of the work. I’m not suggesting you know the technical details, but you should be able to manage a high level discussion. It’s good to know functional requirements too, although you should be able to lean on the analyst for that information. Either way, arm yourself with the knowledge to help direct the effort.

2) Stay in touch with the development team and decisions they are making. You need to depend on the Tech Lead to ensure gold plating is not happening.

3) Request demos as often as it makes sense. Always stay in touch with what the team is developing visually. If you know the scope, you should be able to do a quick visual check on the code. You may not always be able to do this, depending on the stage of development, but it’s an option.

Image: Metal background with power button by Bigstock

6 Responses to “Gold Plating: When Less is More”

  1. Hi Cathlynn,

    You didn’t mention probably the worst consequence of gold plating: increasing customer’s expectations. When you give your customer more than he bargained for on the first project, then he’ll expect the same on all his subsequent projects. Gold plating can lead to the loss of customers at one point!

    • I would agree with you actually – it’s a great point. But there is another angle to look at this – If your team consistently over produces, then they may not just expect it, they may wonder if your estimating process is problematic. It can create a lack of trust with financial and effort estimates. Great point!

  2. Refactoring is not gold plating when it results in more unit testable code. If you have a code base that has lots of defects and a code base where the defect density does not drop, the code needs solid unit tests. Test driven development follows closely with Agile. Any stakeholder has the implicit or explicit requirement of zero defects. Driving down maintenance costs is huge. Too much software is in the state where if you fix one defect you inadvertently create another. Unit testing solves this and refactoring for testability should be done in certain situations. I’m not talking about QA testing either, formal unit testing done by the developers. This should fall on the good side of the fine line you mention – this should not be considered gold plating.

    • Hi Doug,
      By strict definition, refactoring is considered gold plating. If there is a known issue with the existing code at the level you’ve defined, then I would actually suggest that refactoring be considered part of the scope so it doesn’t have a negative impact and is considered part of the delivery.

      I would be concerned that if the level of refactoring necessary to move the project forward is significant, that the team may be considering that as part of their work. Hopefully the PM is able to see that or the team is open enough in the planning stages to communicate this effectively.

      If not, hiding that in the estimates can also cause problems. A seemingly simple project would get inflated. The customer may be paying for more than they bargained for.

      I would suggest from the start that the development team have open communication about these situations so they can plan appropriately for these situations.

      Either way – great point to bring up. Thank you!

      • Of course it cannot be hidden from the estimates. Once they are communicated and approved into the development estimates, then I don’t believe they should be considered gold plating. Far too often though I see business analysts, project managers and developers not able to effectively communicate the value of code clean up – specifically unit testable code, when it is needed. Code clean up with out additional features some times is also part of the development process. There are many times that the new requirements force a very different design/implementation which is another example of refactoring that I feel is not gold plating. You may think of it differently; I don’t know. It is also important to note that developers can be over police’d when it comes to fear of gold plating. Things like commit hooks can be tied to defects will limit what you think is gold plating. I think good communication is the key to balance “good” vs “bad” refactoring efforts and determine which are needed and when. Sometimes software systems are a “birds nest” and are costly to maintain. It just happens. I’ve seen strong resistance to refactoring even when its costs and benefits are effectively communicated. There are always extremes in any spectrum of view. I think I’ve seen an extreme paranoia of gold plating, (of course not what you are talking about), where it can be rejected no matter what. In those cases, I’ve seen very talented developers get very frustrated and leave the company.