Lessons learned from a major failure

21.08.2006

After six months of designing, there was increasing pressure to start programming. Even though the design was still incomplete, the design teams had produced hundreds of pages of specifications, and these were handed off to the programming team. That team was overwhelmed by the volume and complexity of the specifications. (The longer you spend designing a system, the more complex and difficult it will be to build. It's best to design and build smaller pieces in quick, iterative steps.)

To cope, the programmers changed the specifications and cut out features they didn't understand. Also, new releases of the system hardware and software kept coming out, so people kept reworking programs to take advantage of new features in the new releases. Almost a year was spent programming and reprogramming. (System specifications have to be complete and easy to understand. People need to stick to them and not redesign the system while building it; new features can be added in future releases.)

When the beta-test version of the system was finally unveiled, it ran very slowly and crashed constantly. (After all the high expectations and almost two years spent designing and building the system, this performance seriously damaged the credibility of the whole project.)

Programmers scrambled to fix bugs, but support for the system faded. Members of senior management became alarmed at the constantly increasing budget. After another six months, they canceled the project and wrote off millions of dollars. (Delivering smaller subsystems every few months is better than trying to deliver the whole system in a few years. Smaller subsystems are easier to debug, and people see they are getting something for their money.)

Since then, I've successfully delivered many new systems, and much of my success is due to the lessons learned from that failure. What lessons have you learned from your failures, and how have you applied them?