Wednesday, April 9, 2008

Software Engineering in a Blizzard

[Editorial note: This is a rewrite of my previous post. I've preserved both forms to show the differences in style and tone. I also think it plays into the theme of the lessons I'm trying to draw from Blizzard's example as depicted in the source article.]

Colin Stewart posted an article a few days ago touting eleven lessons in innovation that can be found by looking at Blizzard's World of Warcraft game. I'm not sure I would call any of them innovations, but I do think they are worth looking at as an example of good software development practices.

Usability Testing is the formal name for the practice of having people in a real environment test your software to make sure it does what it was intended to do. Blizzard does early and ongoing usability testing by having the developers use the software, a practice known within the industry as "eating your own dog food." This allows (or forces) developers to confront issues with the intent of the software first hand. There is some danger that using their own software can blind developers to an issue that they have worked around or gotten used to through repetition. User interfaces commonly fall victim to this. To combat this problem and expose many others, Blizzard makes heavy use of testing internally, publicly, and on an ongoing basis. Being involved in this testing is optional for the players, with the traditional incentive being early access to new features. The game itself gathers quantitative statistics on how players are using it, these can be used to find subtle flaws in the design or execution of the game. They have an in-game mechanism to report perceived defects, user forums where players can interact with the development and quality assurance teams, and an automated update process to deploy fixes when they become available. Blizzard's quality assurance and ongoing support of their products are a huge selling point for their games, because the customer knows that when the game comes out, it will be relatively solid, and any issues that are found will be fixed quickly.

Talking about continuing support for a software product leads into Blizzard's Software Lifecycle practices. All that ongoing customer and quality assurance feedback must be addressed, and this leads to the idea of continuous improvement. For new development, the emphasis on being able to throw away something that doesn't work is very important, and it runs from prototyping individual pieces to evaluating whether the entire product is coming together. Encouraging failure rather than trying to prevent it allows for a much looser development environment where people aren't afraid to take a risk from time to time. When the risks pay off they can really improve the software, and when they don't they can be quickly removed. Incremental and iterative development facilitates quick fixes, prototypes, and changes by necessitating more modular software. All of this feeds back into the testing and user input cycle to improve the product at every stage of its development and deployment.

Blizzard also addresses that most nebulous of business techniques: motivation. Demanding excellence is a nice theory, but to actually deliver, you have to have motivated people. Peopleware and The Art of Innovation both spend a large number of pages on the importance of a cohesive, motivated team. Giving employees something extra is the icing on the cake of good development practices that can make the difference between a content team and an energized one. Caring not just about the product, but how the employees feel about working on the product is probably the hardest thing to get right in modern software development.

Making sure that as much of the software as possible is done correctly as early as possible is what the field of Software Engineering is all about. Blizzard is one outstanding example of good practices in an extremely demanding area of software development.

No comments: