Two Ways To Build A Pyramid

Some time ago, a pyramid builder was hired to build a tomb for the pharaoh. The tomb had to meet two requirements: it had to be finished before the pharaoh died and it had to be big.

The builder had two problems. He didn't know how long the pharaoh would live and he didn't know how big the pyramid needed to be. To help him answer these questions, the builder worked with a team of physicians, actuaries, and engineers. They worked for years, estimating how many years the ruler had left, how much stone to cut and how many workers to enlist. When the team finally felt confident in its findings, it created a detailed schedule and began construction on a very large pyramid.

For many years, the project progressed well. The base of the pyramid began to rise from the desert sand. Development continued on track until, one day, the pharaoh fell off his camel and died. Immediately, the builder's burgeoning confidence turned to despair, and a few days later the ruler was laid to rest under the flat top of a structure that looked like this:

Mindful of his predecessor's mistakes, the next pharaoh tried a different approach. After a brief consultation with an engineer, he ordered work to begin immediately on a pyramid the size of a small house. As the pharaoh lived, his pyramid grew:

After a long, productive life, the pharaoh passed on, and he was laid to rest in a very elegant monument with a square base and triangular walls that met at a point at the top.

Like the pyramid in this story, the outcome of large software projects depends on factors that are beyond the control of the development team. Shifting schedules, varying functional requirements, budget changes, and evolving technology are factors that sometimes make detailed advanced planning impractical.

Making A Point
Because large software projects have many functional components, a good way to guarantee success is to finish the design, coding, and debugging of each component before you begin the next piece. This Complete Before Continuing process is similar to Feature Driven Development (from Coad, Lefebvre, and De Luca), which starts with an overall model and a feature list, then proceeds with small development steps.

The difference is that Complete Before Continuing is a process that includes the entire team--business development, designers, and information architects--not just programmers and testers. Complete Before Continuing is particularly useful for developing applications where look and feel are of high importance.

For example, when we developed a connected medical news application for a pharmaceutical client, we started by coding a small program that simply pointed to a news site, extracted medical news, and then redisplayed it in a window. After this base functionality was designed, coded, and tested, we were ready to design and program the next component: a module that pulled specially tagged medical data from a medical news wire. For the life of the project, we finished designing, coding, and testing a module before designing and planning for the next.

The Complete Before Continuing methodology is compelling for three reasons. First, useful testing can begin almost immediately, and project managers, information architects, graphic designers, and programmers receive important feedback early in the development process. Second, the team works in lockstep. No part of the team gets too far ahead. Third, the team responds better to schedule and scope changes, because functional, defect-free versions of the application are available prior to the scheduled completion date.

Test Early, Test Often
Complete Before Continuing produces code and content that allows quality-assurance engineers to get an early start on testing, which allows time to fix bugs and make necessary design changes. Also, since bugs beget more bugs, fixing defects early saves time.

Another important benefit of testing early is that the system architects get important insight into hardware requirements. Network capacity, security, load balancing, operating system configuration, storage, failover, and other system requirements depend on usage and application design. Having a testable release of the application early in development reduces the chances of being surprised by load and performance problems at the end of the project.

Complete Before Continuing ensures that some team members don't get too far ahead of other members. In the case of programming, this is particularly important because sometimes the only way to know if a feature will work is to code it and find out. If information architects design too far in front of programmers, it's hard for them to take advantage of what programmers find out in development. In contrast, when information architects design alongside the programmers and adopt a "try it and find out" approach (these quick tests can take just a few hours), it's easy for them to take full advantage of the technology and avoid designing something that might break.

Complete Before Continuing makes it easier for the development team to respond to schedule and scope changes because there is "releasable" software available during development. Unlike the common approach of beginning with a deadline, then estimating how much time to allocate to design and how much time to allocate to the build, Complete Before Continuing assumes the planning and building happens simultaneously. Instead of having only documents, prototypes, and code fragments to show for a long up-front design phase, Complete Before Continuing produces concrete results from the beginning. This simplifies budgeting and eliminates the awkward moment after a long planning phase when programmers wonder if there is enough time left to build what was planned.

John Mayo-Smith is VP of Technology at R/GA, a New York based interactive agency specializing in the development and integration of new technologies. He can be reached at [email protected].

Recommended reading: