~ryanlowe/blog: Bad Release Engineering Can Sink Your Project

Bad Release Engineering Can Sink Your Project

Dave Winer indirectly underscores the vital importance of good release engineering for a software project when he tries to install Sims 2.

It doesn't matter how amazing your software is. If your user can't easily and properly install your product all he has is a few useless (and expensive) polycarbonate discs. You've wasted his time and money and ruined your reputation all in one clean shot.

This case could be particularly damaging to EA, as thousands of people will note that Dave had problems installing Sims 2. Does that make you want to rush out and buy the product or wait for them to patch the problem and stamp new DVDs? Does it make you want to buy it at all?

It doesn't really matter what Dave's issue was, or how minor the problem is. This is probably one of those 1 in 10,000 weird configuration bugs. The bottom line is: it just doesn't work out of the box, and that can lose you customers and essential word of mouth (buzz, viral marketing = more potential customers).

Good release engineering alone can't make a successful software company but bad release engineering sure can sink it in a hurry. Good release engineering is probably underestimated by most software developers, but even on internal projects it is essential. It will save you a lot of time down the road anyway, so why not just do it?

update As thousands of people watch, Dave has more problems. Is it just me or is this very bad publicity?

I should be more clear about EA though, because they probably have very good release engineering. It's one weird case like this exposed by a person in a very public position that can ruin a product release. People will still buy Sims2 but some of Dave's readers may think twice.

Just imagine if Dave was a reviewer for the New York Times and he ran into a weird problem like this. That could really sink your product. On the other hand checking *all hardware configurations*, just like checking for *all possible bugs* is a good way to never ship the product. Shipping is goal #1 people.

Bottom line: minimize risk in your software development. Most of the time it's not practical to completely eliminate even one project risk.

Posted at September 21, 2004 at 05:35 AM EST
Last updated September 21, 2004 at 05:35 AM EST

Comments

I think this is why a lot of game production companies like the console market better. Every system is exactly the same, so you don't have to worry about millions of different configurations, and whether or not your product will work with them. Of course, it's really hard to release a patch for a console game. But that's another problem altogether.

» Posted by: Kibbee at September 21, 2004 08:35 AM

Kibbee: exactly. People wonder why Apple keeps a stranglehold on their hardware. One reason is that it makes their software A LOT simpler to maintain. Far less possible hardware configurations to worry about.

Console development brings new meaning to the word "stop-ship". But the same goes for a lot of "permanent" software, like software-designed integrated circuits and ROM chips, etc. QA is critical for permanent stuff, though games can probably get away with minor glitches that hardware cannot as long as it's still playable.

Just wait until all of the consoles have Internet access. The developers will rush the product out the door because they know they can always just patch it later.

It'll be like Quake 2 and 3 for the PC, with new patches every few months and incompatible versions floating around -- and you can't play until you update!

» Posted by: Ryan at September 21, 2004 08:48 AM