According to Steve McConnell, Gold-plating "comes from developers who want to explore a technically challenging new area..."  Jeff Atwood, in his blog, says that "In the purest sense, all refactoring is gold-plating. That is, it consumes extra project time and results in no material benefit for the users. But without periodic and aggressive refactoring, we can't produce sane, maintainable code."

While I agree with Jeff's conclusion, I would not go as far as he does in equating refactoring with gold-plating. Having maintainable code does have a direct benefit to the customer or client (the person paying for the development).  Ultimately, it's a cost/benefit matter. When the cost outweighs the benefit, then it's not worth refactoring.  Plus, at some point (I hesitate at saying this), the code just works and no further development/refactoring is needed regardless of the code being ugly. Furthermore, when it comes to gold-plating, there is an ill-motive even though it may be subtle. 

I should probably note that when I use the term "developer" I may be referring to a development consulting organization, an independent consultant or a developer (at any level) within a development team.  In all cases, this is a person who can influence the tools and technologies employed in a development effort.

That said, I find that an extensive amount of gold-plating occurs at a much earlier phase of development (such as the proposal phase) which is why I prefer the term "Technology gold-plating" over "Developer gold-plating".  This goes right in line with McConnell's definition.  

I divide Technology Gold-Plating into two categories.

1. New Technologies (Bleeding Edge)
2. Preferred Technologies

New Technology Gold-plating

New technology gold-plating is exactly what the name implies. The developer wants an opportunity to delve into the latest technology.  This is extremely dangerous for the client who may be investing his/her money to the effort.  In essence what is going on here is development research and education at the client's expense.  It works like this. The vendor comes out with a new bleeding edge technology. The vendor pushes it on its partners (who want to play with it). The partners push it on to their clients. Their clients get blood splattered all over them - not good and frankly, quite messy.

Preferred Technology Gold-plating

Preferred technology gold-plating is the use of technologies with which the developer is most familiar or favors for whatever reason. For instance, a developer may use a pre-designed architectural model from the latest popular book on software architecture. Or he may use some pre-fabricated framework.  I am by no means saying these are bad. They are excellent if they actually meet the client's technology and business needs.  Yet, it happens too frequently that a company ends up with an over-architected monolith of a system when all they needed was an html page and a few lines of java script.

So, how does one prevent this from happening to their project?  Stay tuned, I'll be covering this and more in future posts.

I can say unhesitatingly that every project on which I have worked has been a collaborative nightmare.  The reason? Because Email has been the primary means of team collaboration.

I am pretty much sold on the Wiki approach to team collaboration. At this point, I have not personally implemented a Wiki, I am currently in the process of reading about the various options available. Needless to say, I am only interested in free / open source options.  At the moment, I'm considering ScrewTurn Wiki.  I am also anxious to see what Google does with their JotSpot acquisition.

In the meantime, to see why Wiki is good for collaboration, watch this video.

If you have any comments/suggestions on Wiki tools - do tell!

Recently, a colleague and I were discussing the merits of best practices amongst small teams.  The context of this discussion is of a development consulting company; companies that provide development resources from project managers to programmers and testers.

We agreed that "best practices" are often a difficult sell to clients that out source their projects to these consulting companies. The reason is that the there is a notion that best practices are time consuming tasks that offer no tangible benefit, but only perceived benefit.  In other words, to the client, adding an extra X hours to a task that takes X hours to develop and deliver seems like unnecessary time and money. However, there is a serious fallacy to this reasoning. 

Take, for instance, the best practice of code reviews. The whole purpose behind code reviews is to prevent defects in the software and to allow for their repair early in the project life-cycle. Generally speaking a defect costs much more to repair later in the development cycle. Therefore, it is advantageous to  find it and fix it soon. This is made possible through code reviews. 

One study involves a 10,000 line project done by two different groups of developers. One group did not perform code-reviews. The other did.  The amount of money that would have been saved is substantial as shown in the figures below.

Personally, if I am the the customer hiring a development company, I want to make sure that the company performs code reviews, otherwise, I may be agreeing to pay some serious dough when I didn't have to.

If I'm the development company, and if I'm honest, I want to offer my clients the best service for their money. If I really believe that code reviews work, then I am going to work it into the development agreement. If a potential client resists, then I must show the potential cost in my estimate realizing I may not win the client.

I'll leave the analysis up to the reader. For more on this study, go here:  Code Review Study.

Thoughts?