Games & Good Software Design
I have to admit a mild addiction to Team Fortress 2 and Valve games in general. In another life I'd like to think I'd have made a great game developer* and I highly recommend the book Masters of Doom about John Romero and John Carmack's adventure from wayward hobby programmers to creators of the entire FPS genre. But what really attracts me to Valve games are their attention to game design as a science and the way they share their revelations with their customers.
Take the TF2 team's latest blog post about the upcoming Engineer update (for the uninitiated, the Engineer is one of 9 playable classes in this online-only first person shooter team game). They describe the thought processes behind continual improvement of their game:
The goal ... was to solve a perceived problem in the Engineer's play experience: always having to be tied to your base.
This is usually how we approach our game design: Identify a problem, then discuss the ways it could be solved. Our experience told us that even when the Engineer didn't feel immediate pressure, he still couldn't range out away from his base.
Importantly, not only do they test and refine ideas, they recognise when and why ideas don't work. They use these lessons to inform future improvements.
These may seem like obvious lessons, but knowing for certain why a particular idea doesn't work can often be as valuable as an idea that does.
These are lessons that can be applied to almost any programming design choices.
* Incidentally, the first programs I ever made were Basic A pick-a-path text adventures on XT machines. Goto 10 anyone?