|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What Went Wrong 1. Lack of up-front design We never had a proper design document, which meant that we generated a lot of code and art that we later had to scrap. What’s worse, because we didn’t have a detailed outline of what we were trying to build, we had no way to measure our progress (or lack thereof) accurately. We only realized that we were in trouble when it became glaringly obvious. If we’d been about the design rigorous up front, we would have known that we were slipping much sooner. 2. Understaffing at the start
This point is closely related to the previous point. Because we didn’t have a firm design, it was impossible to do accurate time estimates. Red Storm was starved for manpower across the board, and because we didn’t have a proper schedule, it was hard to come to grips with just how deep a hole we were digging for ourselves. There were always plenty of other things to do in getting a new company off the ground besides recruiting, and we were trying to run as lean as possible to make the most of our limited start-up capital. Given the circumstances, it was easy to rationalize understaffing the project and delaying new hires. Additionally, I badly overestimated my own abilities. For Red Storm’s first year, I was working four jobs: VP of engineering, lead engineer on Rainbow Six, designer on Rainbow Six, and programmer. Any one of these could have been a full-time position. In trying to cover all four, I spent all my time racing from one crisis to the next instead of actually getting real work done. And because I was acting as my own manager, there was no one to audit my performance. If one of the other leads was shirking his scheduling duties or blowing his milestones, I’d call him on it. But on my own project, I could always explain away what should have been clear warning signs of trouble. 3. Reliance on unproven technology Our external solutions for rendering and networking both fell through and had to be replaced with internally developed code late in the development cycle. In both cases, we were relying on software that was still under development. The core technology was sound, but we were plagued with inadequate documentation, changing programming interfaces, misunderstood performance requirements, and heavy integration costs. Because both packages were in flux, we failed to do a thorough evaluation of their limitations and capabilities. By the time it became obvious that neither was completely suited to our needs, it was too late to push for changes. In retrospect, we would have saved money and had a much smoother development process if we’d bitten the bullet early on and committed ourselves to building our own technology base.
4. Loss of key personnel Losing even a junior member of a development team close to gold master can be devastating. When our lead engineer took ill in February 1998, we were faced with a serious crisis. For a few frantic weeks, we tried to recruit a lead from outside the company, but eventually it became obvious that there was no way we could bring someone in and get them up to speed in time for us to make our ship date in July 1998. Promoting from inside the team wasn’t a possibility either — everyone’s schedule was so tightly packed that they were already pulling overtime just to get their coding tasks done; no one had the bandwidth to handle lead responsibilities too. Ultimately, I wound up stepping back in as lead. This time, however, we knew that for this arrangement to work I’d have to let my VP duties slide. The rest of management and the other senior engineers took up a lot of the slack, and Peter had set a strong direction for the project, so the transition went very smoothly. (After his health improved Peter returned to work at the end of the project, putting in reduced hours to finish off the Rainbow Six sound code.) 5. Insufficient testing time We got lucky. As a result of our early missteps, the only way we could get the game done on time was to cut deeply into our testing schedule. We were still finding new crash bugs a week before gold master; if any of these had required major reengineering to fix, we would have been in deep trouble. That the game shipped as clean as it did is a testament to the incredible effort put in at the end by the engineering team. As it was, we still had to release several patches to clean up stuff that slipped through the cracks. ________________________________________________________ |
|||||||||||||||
|
|
Features
