Gold Plating

Why “gold plating” is a lousy name

~ Andrew Stellman ~ 2 Comments

A few days ago I posted an answer to a question about gold plating and scope creep to the Head First PMP forum. I’m not surprised the question came up — people really seem to have trouble with the concept of gold plating. And I don’t think it’s because it’s a tough concept to get. I think it’s because it’s got a lousy name.

Gold plated silverware

In the usual gold plating scenario, a programmer adds features that were never requested because they’re “cool” or fun or seem like they’d be really useful. And sometimes they are — but more often, they’re just wasted effort, at least from the perspective of the person paying the programmer’s salary. Like I pointed out in my last post that mentioned gold plating, I completely sympathize. I’m definitely guilty of gold plating. There was one project I led about ten years ago where I created an entire scripting language, complete with interpreter, that was totally unnecessary. As far as I know, that product is still being used today, and not a single person has ever written one script for it. But it was definitely cool (or, at least, I thought so). More importantly, I really did think it would be useful, and make the software better. Classic gold plating.

On the surface, the “gold plating” does seem intuitive, but the analogy starts to break down under closer scrutiny. Think about what gets gold plated: all sorts of stuff, from cheap jewelry to expensive pens. All sorts of things get encrusted with, for lack of a better word, bling. And that’s what I pointed out in that forum post:

Gold plating is what we call it when the project team does work on the product to add features that the requirements didn’t call for, and that the stakeholder and customer didn’t ask for and don’t need. It’s called “gold plating” because of the tendency a lot of companies have to make a product more expensive by covering it in gold, without actually making any functional changes. (For example, there are plenty of watches and fountain pens you can buy from luxury companies that are identical to their cheaper versions, except that they’re covered in gold.)

This got me thinking about gold plating, and why it gives people so much trouble. Is gold plating in a software project actually similar to gold plating in real life? Or is it an odd, somewhat mismatched analogy?

To answer that question, we’ll need to take a step back and look at gold plating in the real world. There are a few different strains of gold plating, and they serve different purposes. First there’s the traditional, purely decorative gold plating. That’s the one we know and love: take an ordinary object, slap some gold on it, and charge a whole lot more. That’s the sort of product that’s associated with decadence and conspicuous consumption. It’s where the Gilded Age got its name.

Certainly, making a product arbitrarily more expensive is certainly a way to sell more of it to a certain sort of consumer. But while there are certainly numerous modern examples of opulent gold plating, it’s fallen out of favor somewhat. More importantly, it’s not really a great analogy for gold plating in software.

What it’s been replaced with is a somewhat similar but definitely distinct way to enhance (read: sell “upscale” versions of) products. This “enhancement” is done by adding features that are actually useful, but go far beyond the needs of the typical consumers of the product.

Here’s an example. Hhow many suburban homes really need an industrial refrigerator or restaurant-quality range? Those appliances have been a selling point of “luxury” and “upscale” homes’ kitchens for years. But the difference between that and, say, gilded kitchen items is that the “professional” applicances almost certainly worth the price — if you actually need them. Which you don’t, if you only use your kitchen to cook dinner for four every couple of days and thaw the occasional frozen turkey. But that’s not the point. The kitchen itself has been “upgraded” with cool but unnecessary items. And, in this case, it sells.

Canyonero

That’s certainly not the only example of products packed with features that are potentially useful, but which are, for the average owner of those products, essentially unnecessary (and by and large unused). There’s the slowly fading American love affair with the SUV; the top-of-the-line faucets, fixtures, and general home accouterments that litter the country’s McMansions; and pretty much everything in the Brookstone, Hammacher Schlemmer and Sharper Image catalogs. We’ve got our fill of amateur hill climbers with professional mountaineering gear, weekend golfers with $1,500 titanium clubs, and basement workshops stocked with industrial hardware used to build the occasional birdhouse. Every single one of those things, in the right hands, is almost certainly worth it. I’ve been playing bass guitar for about 20 years, and I know that there’s a big difference between the average $300 instrument and one that cost ten times as much. (Which is not to say you can’t spend $3,000 on a crappy bass, but that’s a whole different issue entirely.) Certainly, a beginner will see some small benefit from using a better instrument. But it’s probably not worth the price for someone who will only pick it up once every few months.

Neither of these two ideas is a perfect analogy for software gold plating. In some ways gold plating in software is a lot like like gilded products. In other ways, it’s similar to the kind of overkill that people perform when they use “top-of-the-line” products unnecessarily. More accurately, it’s really a mixture of the two.

So what drives us to gold plating? We add unrequested (and eventually unused) features because we want to build stuff that’s cool, and it never occurs to us that we’re building something our users won’t need. I like to think of Google as the ultimate in gold plating. Their latest offering, Google Street View, is a great example of cool software that doesn’t seem to meet an obvious need. And I love it — I think they did a great job with it, and I’m honestly impressed with the way a whole lot of moving parts came together the way they did. Maybe someone will think of a really great use for it. But isn’t that a solution in search of a problem, by definition?

A good rule of thumb is that people will generally only pay for a product that’s useful. One of my favorite ways to describe quality is to consider two pieces of software. The first one is beautifully designed, very well built, very stable, never crashes, has a very intuitive user interface, is extremely secure, and is generally a pleasure to use — but it doesn’t do the job you need it to do. The other is terribly built, painful to use, crashes at least once a day, and does 50% of what you need. And that’s the one you’re going to use. It meets your needs. And any feature in that software that doesn’t meet your needs (or the needs of any other users) is pure gold plating.

Which brings me back to the name. I don’t think “gold plating” does justice to the real phenomenon it refers to. It’s more than just gilding software by making it pretty (and/or more expensive). It’s about the way we genuinely feel that we’re making the software better by adding features that may be really cool, but which we, as programmers, simply don’t recognize are useless.

And the sooner we can figure out how to avoid doing that, the better our software will be.

(Luckily, we’ve got some really good tools to help us avoid gold plating. I’ll talk about them soon in another post.)

The Kitchen of the Future

~ Andrew Stellman ~ Leave a comment

A clear need for a better kitchen

What is it with futuristic kitchens? I swear I’ve seen the same TV segment about the “kitchen of the future” repeated on different channels with different people at least twice a year for the last decade or so.

This wired article seems to have a good description of the generic kitchen of the future:

Kitchen of the future
General Electric
What if your appliances were so smart they took the drudgery out of meal preparation? “Your kitchen can basically be your sous chef,” says Marc Hottenroth, an industrial designer who helped create GE’s concept kitchen. Call home from work and your pantry and fridge – outfitted with RFID readers – will tell you what’s stocked, suggest meal options, and list the ingredients you’ll need to pick up at the grocer. (They’ll also remind you to buy milk when you’re almost out.) Craving a quiche? GE’s kitchen will guide you through assembling one and heat the oven to the optimal temperature. If, say, elderly Aunt Rosa is visiting from Italy and wants to whip up some gnocchi instead, the appliances can display text in larger type … and in Italian. What’s more, GE’s setup redistributes energy (such as using excess oven heat to warm dishwater) to lower power bills. Rather not cook tonight? The kitchen can find a number for pizza delivery.

There you go! It’s got everything. It gives you recipes, tells you what’s in your fridge, and lets you look up phone numbers. All that, and it will remind you to buy milk.

Sounds great! So why does the kitchen of the future rub me the wrong way? And, more importantly, what lessons about building better software can we learn from the kitchen of the future?

Let’s put aside for a moment the fact that it’s pretty unlikely that your elderly Italian aunt Rosa doesn’t already how to make gnocchi. There’s one thing that’s true about every engineered product, whether it’s a stove, software or a slide rule: it’s built to meet someone’s needs. But there’s another thing that’s almost always true: some needs aren’t obvious. And it may just turn out that you’re building a kitchen that doesn’t actually meet real needs that people have.

Here’s an example. A hat seems like a pretty simple product that meets a straightforward need, right? It keeps the sun off your head. But wait a minute… plenty of people wear baseball caps inside, where there’s no sun to protect you from. And they’re not playing baseball. So hats fill another need — they help the wearer feel fashionable. And there are other needs, too. A baseball cap has a visor that’s placed in a way that shields your eyes from the sun, but it also advertises a sports team, and, when adorned with the proper Greek letters and bent in exactly the right way, makes frat boys look cool to other frat boys. Those are all important needs.

What about a toy program that you just threw together in your spare time because you were bored? Does that fill a need? Sure! You needed to kill some time, and it served that need perfectly.

So what does all this have to do with the kitchen of the future?

The perfect kitchen GUI?

Take a minute and have a look at this excerpt from a CNN transcript of a segment about one particular kitchen of the future:

TIM WOODS, VICE PRESIDENT, INTERNET HOME ALLIANCE: This is kind of a nerve center for the entire kitchen. In fact, it’s the nerve center for the home. This is the HP TouchSmart PC. And it’s kind of social computing, right, at its best.

But the idea here is, you put everything in one place at a touch point. There’s a middleware program on this from a company called Exceptional Innovation. And what that did is, it brought all of these elements like lighting and shade control and music, and put them all into one interface. Now, mom does about 80 percent of the input on any family calendar, but she wants the ability for dad to go in there, the kids to go in there, leave notes – do all of these things that really become tools for the family.

Now, I don’t want to knock HP and Exceptional Innovation. I’m sure they worked hard on their software, and I certainly know what it’s like having a product to sell. And they’re following the siren call of the Kitchen of the Future that plenty of people have followed before, and I can’ blame them for that.

But really? Controlling the lights and keeping a family calendar — is a computer really the best way to do that? Most families have a dry-erase board or calendar stuck to the fridge. It meets their planning needs really well. It’s much more Agile. (And, interestingly, it never crashes.) Think about it from a software development perspective: do you want to go through a whole bunch of screens in a touch-screen GUI to get to your calendar? Or do you just want to go scrawl a note with a marker? Which of those seems “heavyweight”? Which seems more agile?

The same goes for controlling the lights and the entertainment center. Most kitchens have a small handful of lights. I’ve yet to find a software interface that works better than a light switch or a dimmer on the wall. Plus, you can find a light switch in the dark when you’re half-asleep and looking for a midnight snack. I’d be surprised if that’s a need that most lighting control software developers realistically considered.

Which brings me to buying milk. Just about every Kitchen of the Future I’ve seen in the past ten years makes a point of being able to tell you that you’re out of milk. (On the video, the computer in the CNN segment showed an image of a Post-It note displaying a hand-written note that read, “Buy milk!” I have the feeling that showing a picture of a Post-It note seems, from a UI perspective, to be an admission of defeat.) Is it a real need? Yes, with the exception of or vegan friends, we do all need to buy milk.

But is it really so hard to figure out when you’re low on milk?And if it is, can we realistically expect the kitchen to know when we’re low on milk? Will we always need to put the milk on a special Lose Weight Exercise sensor? Will I get a false alert when little Kaitlynne or Brandyn puts the milk back on the wrong spot in the fridge? Does it know when my milk’s gone bad, or only if it’s low? It all seems far more complex and error-prone than just having a stack of Post-Its and a marker next to the fridge. The simplest and most convenient solution to the problem is still scrawling “buy milk” on a Post-It and sticking it somewhere obvious.

And that’s my point. When you get down to it, the Kitchen of the Future is available to us today at a reasonable price. Why don’t we all have one? Because it doesn’t meet a need. It’s an Lose Weight Exercise in gold-plating. It’s a solution in search of a problem. And I get it. I’m a programmer at heart, and I love new applications of cool technology significantly more than the next guy. But we won’t find buyers for our products if they don’t fill a need.

And that’s the software lesson to learn here. Make sure your software always meets someone’s needs before you start building it. Because the last thing you want is to put your Kitchen of the Future out there, only to discover that the world’s just not ready for it yet.