IASA / NYCJava – thanks for having us by!

~ Andrew Stellman ~ 1 Comment

Jenny and I had a great time doing our “Why Projects Fail” talk at a joint meeting between the International Association of Software Architects and NYC Java SIG (a couple of announcements) at the Microsoft office in midtown Manhattan last night. (Fun trivia fact: my first job out of college was in the same building, working as a programmer at EMI-Capitol Records.) It was an after-work session, so we’d only expected to spend half an hour or forty-five minutes, but we got so many great questions from people that we kept going until the folks at Microsoft had to close down the meeting room.

Why Projects Fail presentation screenshot

We promised to upload the slides and post a couple of links, so here they are. Here’s the PowerPoint presentation [PPT] and a PDF version [PDF].You guys asked great questions — some of the best we’ve ever gotten at one of our talks. Here are a few of the answers that we promised:

  • A few of you had questions about estimation, specifically the Wideband Delphi process that we’ve had a lot of success with. You can read about it in Chapter 3 of our first book, Applied Software Project Management— here’s a link to a PDF of the chapter [PDF]. We give a pretty detailed description of exactly how to hold a Wideband Delphi meeting, and how you can use it on your own projects to improve how they’re estimated.
  • One person brought up a really good point about integration, and how that’s an important failure point that gets neglected, and we mentioned that we’d post a link to an article we wrote for Dr. Dobb’s Journal on integration testing called “Better, Stronger, Faster Integration Testing: Giving developers a personal stake in software quality.”
  • I think a lot of the questions near the end of the talk about open source projects were answered in our ONLamp.com article called “What Corporate Projects Should Learn from Open Source”. Also, here’s a link to the “What Makes Open Source Projects Work” presentation I gave last January at the SD Best Practices India 2007 conference.
  • No, we don’t have an official release date for “Head First C#” yet, but we’re definitely making good progress on it. Keep watching this blog — as soon as O’Reilly has an official release date for it, we’ll post about it. And yes, it is really fun to write a Head First book.
  • After the talk, a few people asked about our availability to come in and do training. Our consulting schedule is a little tight because of our pretty aggressive writing schedule for O’Reilly, but we do have some availability. You can use our “Contact Us” page to get in touch with us about consulting and speaking — serious inquiries only, please.

We’re always happy to answer questions about anything we talk or write about. Feel free to get in touch with us any time!

Critical path method drill — boost your PMP exam score!

~ Andrew Stellman ~ Leave a comment

Jenny and I put together a new PMP exam preparation drill to help you study the critical path method, an important topic for the PMP exam.

We spend a lot of time talking to people who are preparing for the PMP exam, and one concept that comes up over and over is using the Critical Path Method. It’s a somewhat tricky thing to study. Project managers preparing for the exam often have trouble with it, because it’s not just something you can memorize. Which is a shame—because once you understand the ideas behind it, it’s really useful… and a quick way to get some extra points on the exam. (Not to mention that it can help you in real life too, by helping you find the activities in your project that have the most risk.)

But even though this material is important, it’s often neglected in PMP preparation materials. We’ve found that a lot of people don’t understand it very well, and take the exam anyway. And it’s not surprising. When we were studying for the PMP exam ourselves, both of us were disappointed with the lack of a good guide to really help you learn these concepts. It’s one thing to memorize a bunch of stuff for test day. But it you really want to get it, you need two things: a good understanding of the real ideas behind critical path analysis, and a lot of practice. That’s what’s in these pages. We’ll take you through the concepts and their applications, and drill you on your knowledge. By the time you finish this, you’ll have a good handle on it… and you’ll definitely do better on the exam!

Head First PMP Links:

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.)