Over a million developers have joined DZone.

The Challenge: Successful Design vs Gold Plating

DZone 's Guide to

The Challenge: Successful Design vs Gold Plating

Zone Leader, John Vester, talks about the challenge of delivering a successful design without introducing gold plating along the way.

· Agile Zone ·
Free Resource

Most application development professionals maintain a great deal of pride in their work, especially when developing a new product or feature. The desire is to not only meet the noted requirements but to also do so in a way that closes all the gaps in the developer’s mind. 

Some items for consideration are as follows:

  • Complete logic resolution within the code base - handling every scenario that could arise.

  • Refactored and optimized code.

  • 100% compliance with company standards or industry best practices.

  • Full code coverage for unit and integration tests.

  • Styling that is truly shared across the source application.

  • Adding functionality that *might* be of use.

The challenge for most developers is realizing and understanding what is truly required for the request and what is considered gold plating.

What Is Gold Plating?

Before getting into discussing the challenges with gold plating, it might be a good idea to clearly define gold plating:

" Gold plating in software engineering, or project management, or time management in general, is a term used to describe the error of working on a project or task past the point where the extra effort is worth the added value." - Wikipedia

When working on a project, the idea of gold plating almost always surfaces in one aspect or another. Most of the time, it isn't realized by the gold platers. As artists, they have a vision for their masterpiece and that includes aspects that would be considered more than is noted in the acceptance criteria. There are even times when gold plating is pushed onto other members of the development team, from a development lead or someone in a similar capacity.

In my last such encounter, I wasn't the one doing the gold plating, it was the other developers on the project who spent time reviewing my code as part of a pull request. In this case, my code was fully functional and met the acceptance criteria of the assigned story - but suggestions were made to perfect the code which did not add value that would be noticed by the product owner or end-user of the application. 

What's Wrong With Gold Plating?

In essence, gold plating is adding unnecessary costs to a project by absorbing time from the project to provide updates to the code base which are not visible to the end-user. Considering the limited amount of time most features remain unchanged, often this extra work is tossed aside as new features are introduced as a result of an ever-changing business world. 

In a recent example, our project had a hard-stop date that we had to meet, based on the needs of the product that was being developed. Basically, we had to be done by a certain date. In my case, I was somewhat surprised to see the updates that were requested, given the amount of time required to make the modifications, while a number of stories still remain untouched and required before the target date of our project.

That is like working on a project that is developing tax software. There is certainly a target date where such a product needs to be completed in order to cash in on the customer base looking for a solution to assist with their income tax preparation. Certainly, the TurboTax design team at Intuit would not consider releasing their product in April, so that features could be perfected.

My Thoughts

For a long time, I struggled with gold plating, wanting to make certain that the code I generated represented the best product I could provide. Early on, I would find myself reflecting on the checked-in code during my commute home, only to do a little more "polishing" (a nice word for gold plating) of the code and performing just one more check-in before calling it a night. While I was in a full-time corporate employee role, I failed to realize that I could have spent that time doing something other than perfecting code that was ultimately going to change again, due to evolving business needs.

I also understand the idea of having standards, along with optimized and refactored code, but that is what a technical backlog is for in an Agile environment. The focus should be to be aware of the standards and existing code base as much as possible before starting development. If something is missed during development, create a task or story for the backlog and focus on the next priority story on the planned list. During the next Sprint planning session, the backlogged task can be reviewed and prioritized appropriately.

What are your thoughts? How often do you find yourself gold plating your code? Or, how do you handle being on a team with one or more gold platers?

Have a really great day!

agile adoption ,scope creep ,backlog ,agile

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}