Tuesday, April 8, 2008

These Should Be Standard Practice, not Innovation.

[Editorial note: After writing and posting this, I realized that I was very unhappy with the tone and style. I have attempted a rewrite that is more in line with what I had intended to convey, but in the spirit of the development practices I am trying to defend, I will leave this up as a comparison.]

Colin Stewart put up an article a few days ago touting eleven lessons in innovation that can be found by looking at Blizzard's World of Warcraft. Many commenters have pointed out the inaccuracies of using World of Warcraft as an example of innovation, but I'm going to take a wider view and claim that not a single one of the so-called innovations are new to the software industry. Hopefully, I can demonstrate that what the reporter sees as innovation is just good engineering practice at work. Please don't confuse this with an insult to Blizzard; I hail the work that they have done as examples of what you can get by fusing great design, art, and software. They absolutely should be held up as an example of excellence in one of the most challenging branches of software development.

Here is the list of "innovations" cited and why I believe they are not innovative at all in the context of modern software engineering:

1. Rely on critics.
Studying how end users interact with your product is formally known as Usability Testing. This form of testing is a must for any product to succeed, and to its credit, the article does mention alpha and beta testing. These forms of testing are both extremely common and not the only means of usability testing.

2. Use your own product.
Software developers know this one as "eating your own dog food" or simply "dogfooding." This too is a form of usability testing.

3. Make continual improvements.
The philosophy of always fixing issues you find in your product is encapsulated neatly by Tip 4 from The Pragmatic Programmer: Don't Live With Broken Windows. The various philosophical movements within software engineering that are collectively known as agile development have elevated the idea of continuous improvement to a central practice.

4. Go back to the drawing board.
This is just prototyping. The generally ephemeral nature of software development can allow you to do these sorts of things at a much finer grained level than physical prototyping. The Pragmatic Programmer not only advises using software prototypes, but goes so far as to advise that no decision is final (tips 14, 15, and 16).

5. Design for different kinds of customers.
This one appears to me to be a mass-market special case of designing for a particular market. I'll also refer you to Joel Spolsky's 2002 piece about the different realms of software development.

6. The importance of frequent failures.
As was kindly pointed out by the representative from Blizzard, "fail early, fail often" is not a new innovation. It's reached the point where it's enough of a meme in the software development community that it's hard to pin down the original source. See also the Rule of Repair in Eric Raymond's The Art of Unix Programming for a direct application of the philosophy to the operation of software programs.

7. Move quickly, in pieces.
Incremental and iterative development and self-contained features have been a well understood part of the software development since at least the mid 90s. See also the Lifecycle Planning chapter (7) of Steve McConnell's book Rapid Development.

8. Statistics bolster experience.
I don't think I will even need to dignify this one with a comment on the roles of quantitative and qualitative data.

9. Demand excellence or you'll get mediocrity.
This item isn't innovation, it's motivation. Though I will concede that the art of proper programmer motivation seems to have vanished from large swaths of the industry.

10. Create a new type of product.
Calling creating a new type of product an innovation looks to me like something of a tautology. And using the particular Blizzard property in question as an example is somewhat silly. Blizzard's reputation is built on the quality, depth, polish, and support of all aspects their games. They are generally known as perfectors, not innovators. Nowhere is that pattern more obvious than in World of Warcraft.

11. Offer employees something extra.
Again, we are talking about motivation. Motivation is critical to innovation, but it's hardly a new concept. See also Peopleware and The Art of Innovation.


Lee said...

Hey Brian - I have to second your premise. This stuff ain't new. But then, that doesn't mean it is easy (or cheap) to do so. Seriously, the cost factor of implementing those probably seems like too high a burden. If you can turn out mediocre stuff for a guaranteed profit margin, why bother? Still, when you do and when it works, you get something phenomenal, like Starcraft (which I still pull out every now and then) or WoW. I feel like I can guess what other companies really try to do this: Apple, Pixar, Valve to name a few.

Brian said...

It should say something that "Good is the enemy of great" is the title of a best selling business book. But you are quite correct, great software is difficult, expensive, and time consuming. For all of Blizzard's success, they have a history of taking longer to develop software than they initially planned. But computer gaming is a field driven by big hits, so in that field it's certainly worth taking the time and expense. That's where the know your market bit that I glossed over comes in.

I will claim you still have to be careful turning out mediocre stuff because your profits are only guaranteed if you are a virtual monopoly for the product. (Microsoft Office historically and iTunes currently spring immediately to mind as examples of such a virtual monopoly.)

That said, I'm demonstrably not a business person. I've long held the belief that commodity software is an oxymoron. Even when software starts off as a loss leader to support another product, it has the potential to change the game in ways that physical products never do (again, look at iTunes and the iTMS).

PS: Do check out the next post for a rewrite of this one, I pretty much think this version of the post stinks.