Mischiefblog
I make apps for other people

Band aids? Upfront process and design are better

Posted by Chris Jones
On December 29th, 2007 at 10:37

Permalink | Trackback | Links In |

Comments Off on Band aids? Upfront process and design are better
Posted in Design Journal, Tech

From Zubon of Kill Ten Rats:

Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound. You must tear them all off and throw them away. But at least you get to do all those things you wanted to do if you had it to do over again.

And this is why we Unit Test.

Games that ship and have few bugs have well developed and scrupulously followed development processes. Games with bugs just get shoved out the door because scope creep and featuritis are given more importance than good project management. And for one-off, traditional single-player games, it wasn’t so bad, especially when the game developers were also designers and a four person development team was big. Check out High Moon Studios’ “Day in the Life” seminal article on SCRUM and Unit Testing a modern console game.

An MMO is more like a corporate ERP system than a Pac-Man or Tetris clone, and cutting corners to hit deadlines or out of sheer laziness (and believe me, programmers are lazy–it’s a virtue) helps create emergent behavior or bugs. Strong, comprehensive Unit Testing at the cost of adding dubious features to still meet the development schedule is the best defense against this. The Unit Test becomes a kind of document, an artifact that demonstrates how the developer believed the code was to be invoked and what it should return, and future changes against the code can be verified with execution against the entire suite of Unit Tests. The designer, developer, and producer will sleep well at night knowing that the vision has been translated to code or scripts accurately.

Unit Testing saves the business
One project team (that I’m not a member of) at work has a huge Unit Test suite, covering every input, output, and process within their system. Automated continuous builds, testing, and notification of failures keeps the team’s efforts in-line with the design and correct, any bugs are found early and resolved quickly, new bugs or behaviors become new unit tests, and the system is able to perform apparently flawlessly for customers who have built businesses around this product. Quality as a measurable indicator of the code and implementation of the business processes is very high. Downtime for maintenance or a fundamental error in the implementation of this service means customer businesses fail.

The second implementation is the one we get right
When the second (or third) implementation is the one that really fits the customer needs or desires, the real problem is that the project needs were never really well defined in the first place. Consider the project in terms of:

  • scope – is any phase, iteration, or task within the project larger or more encompassing than it should be?
  • business needs – does the phase actually solve the real business need, or does is solve what the project lead and customer believe is the business need?
  • design – does the design reflect the business need accurately?
  • detail – is the design to be implemented by the task sufficiently detailed, and is the task detailed such that it reflects the real work to be done?
  • duration – is the task duration accurately estimated?
  • break-down – has the task be broken down or deconstructed such that it represents a low-level unit of work?
  • unit tests – the unit tests should be written before the implementation, even if it means that tests won’t compile yet. Likewise, development tasks need to provide full code coverage of the added or changed code, and the task must include black box testing and automated regression testing.

Assigning a task to a developer like “Implement the networking library” or “Add the magic system” is a good way to get an incompatible, buggy, or poorly designed and documented system. If the project manager/producer, designer, and lead developer work together to examine each task and split it into specific, low level tasks, they’re more likely to accurately estimate the project and prioritize tasks, find flaws or missing tasks, and get the product shipped. When my team does this well at work, we’re cooking. When we screw this up, we miss our deployment date by weeks.

Comments are closed.