Where's The Happy Medium Between Gold-Plating And Shoddy Work?

I think sometimes the line between "not good enough" and "better than it needs to be" is about the width of a razor blade (not that I know all that much about razors!). And that slim of a margin for error is not a very easy target to hit, especially amidst the chaos, pressure and distractions of most software projects. So what can we do to make the situation better?

Well, first I think that we need to examine what's really happening whenever accusations of "gold-plating" come up. I've seen it often enough in the past 22 years to at least have some ideas on it by this point in my career. The most common culprit always seems to be time, in the sense of there never being enough of it. When a customer, or project manager, or really any stakeholder with their ass on the line has their eye on the calendar, "finishing touches" can quite easily take on the appearance of "make work projects" or "endless tweaking" (and I don't mean the kind that requires amphetamines!).

To appreciate that perspective, just imagine that you've gone to pick up your car after a repair. You're in a hurry because someone's waiting for you and you told them that you'd be there by now, only to take longer than expected to get to the garage and then find out that the car's almost-but-not-quite ready. You then catch a glimpse of the mechanic busily doing what looks for all the world to you like a polishing job on your hubcaps! Of course you'd be frustrated at that scene, because as far as you're concerned you'd much rather get where you need to be right now with dirty hubcaps than arrive there later with 'caps that look brand new. But what if what was really going on was that the mechanic was checking out your tire pressure and using a rag to clear the tire well enough that he could read what the pressure should be? Most people would agree that having your tires checked is hardly "gold-plating," but you may not even know that that's what is actually happening from your vantage point. And on a more relaxed schedule, you'd simply trust that the mechanic knows what he's doing rather than jumping to any unfortunate conclusions. Start the clock ticking, though, and that whole willingness to extend trust may go right out the window... unless we make a conscious effort to be aware of that trap, and avoid it.

Now, that first point assumes that it's a simple lack of understanding that's creating the conflict. The software developer, in that case, is engaged in some activity that he or she has every reason to believe is required, in their expert opinion; meanwhile someone less involved leaps to the wrong conclusion about it being unnecessary. That's certainly not going to be the only scenario that can result in "gold-plating" charges being thrown around, though. Another possible cause is that there actually is work being done that is above and beyond what's needed to complete the job satisfactorily. So how do developers know when they've reached "good enough" with a piece of functionality?

One obvious way to answer that question is to ask another one: "What's the likely result if I don't do this next bit of work?" If that query can be posed and subsequently answered honestly, then I think we'd have far fewer confrontations of the sort discussed in this blog post. Most of the time, though, I suspect the question's not even being asked; and of those times when it is, then all too often the answer offered up is at least somewhat disingenuous. Why would a developer not honestly answer it? Because they may have an agenda (hidden or otherwise) that's not necessarily related to customer satisfaction. Some examples would be:

• "This code is too hard to work with unless I change it to look like what I'm used to."
• "The customer might ask for this functionality in the future so I need to put it in now."
• "I've thought of a case that will probably never happen, but if it did this code might possibly break so I'd better rewrite it."

That's not to say that any of those responses are categorically bad; just that they might not be reason enough to dictate that something's not ready, and therefore delay a release. And even a whiff of that sort of thing can cause the cries of "Gold-plating!" to go out.

So there we have two of the many ways in which this unfortunate situation can arise. To guard against them requires greater transparency, communication and honesty than we might naturally demonstrate if we just went about our business with our heads stuck in the sand. Living up that higher standard is a lot to ask of us all, to be sure; but as skilled professionals who take pride in our work, we can do it... can't we?