That problem's too boring for you?
Your vast intellect is wasted on your customer's silly needs?
Have I got a solution for you!:
PrematureComplexity & AccidentalComplexity, and have a heyday!
If your coworkers question you, assume they're idiots who can't code their way out of a paper bag! (Or, in this case, a paper hypercoagulative entity-containing megadevice!)
Hint: This is an AntiPattern
It's possible to do gold-plating by accident. Usually it happens when you program a little bit in a lot of languages. You have a problem P, and it has simple solution Q which is immediately obvious to you. But solution Q is in language X, and you're using language Y. So what you end up trying to do is implementing enough of X in Y that you can implement Q the same way you did in X. You've made a bigger problem that way.
I program in SchemeLanguage and ForthLanguage. They are entirely different languages. I was trying to write a pattern matcher in Forth, but I had written several of the things in Scheme, and everything that occurred to me had to do with (a) lambda expressions, which can be used to combine two parsing rules into a single parsing rule, and (b) ContinuationPassingStyle, which can be used to pass every parsing rule two continuations, one to use if it succeeds and one to use if it fails. I was also thinking of ConsCells, of course, and car and cdr. That's how you do this stuff in Scheme.
So I started to think of how I could implement some kind of CPS in Forth, and before long it seemed that garbage collection had been dragged in, and CallWithCurrentContinuation, and I found myself getting carried away trying to implement most of Scheme in Forth. It is not impossible to implement Scheme in Forth, but since I had never actually done it before I was finding it pretty difficult. It posed a bunch of other hard problems which I hadn't considered. Most of those problems were just as hard as the original pattern matching problem. (After all, a Scheme interpreter is just a bunch of rewrite rules, anyway, isn't it?)
Months later the solution occurred to me. It didn't occur to me all at once, either, but in stages. At one point enough of it was revealed that I could code. I successfully implemented a pattern-matcher in pure Forth. It does not require Scheme's lambda forms, or garbage collection, or continuations. Nor does it create Forth implementations of any of those things. But you can see certain similarities between the Forth pattern-matcher and the Scheme ones I had written before.
I'm pleased with the elegance of the solution but if someone had shown it to me two months ago I would have probably rejected it -- unless they took the trouble to show me first how the solution did the same thing the Scheme solution would do, only without the need for most of Scheme.
My conclusion is that GoldPlating, at least in some cases, comes from thinking of a solution in the wrong programming language and then trying to mechanically translate it to the language actually in use.
I already wrote that RestrictedProgrammingLanguages in particular can make GoldPlating worse -- but GoldPlating can happen even in a relatively unrestricted language. It's the language mismatch that causes it.
[...] when you look for challenges and interesting ways to do things, there is always the risk that you will spend your time entertaining yourself rather than doing what you are getting paid for. It's important to keep some sort of objective view of what you are doing to avoid boring tasks, and continuously evaluate whether it is really productive or if you are "just screwing around". When programmers turn simple problems into complex ones just so that they are more fun to work on, that's a smell too. --KrisJohnson
I agree. Most of our prisons are of our own construction. When we do a little more than the customer asks, we have to drag that little more along for the rest of the journey. And the customer has no sympathy for our burden. When we do a little less than the customer asks we get to finish early, have a nice conversation with the customer in a relaxed environment, and cheerfully charge off to do the two more things the customer really wanted out of the fifteen we had thought of. Doing those two more things well is fun too. The GoldPlating is on the handcuffs. -- WardCunningham
Copied from CreepingFeaturitis:
When I joined Tektronix I attended an engineering orientation where the founder of the company, Howard Vollum, spoke. After a few light comments about his long-time rival, Hewlett-Packard, he focused on our real enemy, CreepingFeaturitis. I was struck by his intensity. It took me a few years to integrate his comments with the company motto: committed to technical excellence . He was right, of course. You'll never find the exquisite solution to a real problem if you are busy tending little problems of your own making. -- WardCunningham
it is implied above that GoldPlating is a result of programmers thinking that problems are too boring/easy - it seems equally likely to me that pathological attention to irrelevant details could result from reluctance to tackle the meat of a particularly difficult problem. -- MoeAboulkheir?
Being of the EverythingIsRelative mindset, calling it "pathological" my be misplaced in my opinion. They just may be in the wrong specialty. There's a place and time for such fastidious personalities. For example, see the software QA article referenced in the SpaceShuttle topic. Hell, maybe the GrammarVandal can get a job in their documentation department.
Of course, the million-dollar question is: is well factored code GoldPlating? What about safe code? Is protecting yourself from buffer overflows just overcomplicating things because YouArentGonnaNeedIt? I mean, where is the line between wiping the stinking CodeSmell turds off the wood and electroplating precious metals onto it begin?
Speaking of millions of dollars, isn't there also an impetus on the part of contractors to do GoldPlating to extend the lifetime of contracts? Are there not other impulses at play here other than boredom or BondageAndDisciplineLanguage? -- MalcolmCampbell