News
Commentary
10/17/2001
10:22 AM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Two Ways To Build A Pyramid

The outcome of large software projects depends on factors that are beyond the control of the development team. That's why our guest columnist, John Mayo-Smith, VP of Technology at R/GA, recommends that teams finish the design, coding, and debugging of each component before beginning work on the next.

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:

Flat top

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:

Growing pyramid

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 JohnM@rga.com.


Recommended reading:
  • Brooks, Frederick P. Jr., The Mythical Man Month: Essays on Software Engineering. Anniversary Edition. Addison Wesley, 1995.

  • Coad, Peter, de Luca, Peter, Lefebvre, Eric, Java Modeling in Color with UML, Prentice Hall, 1999.

  • Raymond, Eric, Young Bob, The Cathedral and the Bazaar : Musings on Linux and Open Source by an Accidental Revolutionary, O'Reilly & Associates, 2001

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
anon9350577560
50%
50%
anon9350577560,
User Rank: Apprentice
3/12/2014 | 10:56:36 PM
Two Ways to build a Pyramid
The scinario does not work. 

"The tomb had to meet two requirements:
  • it had to be finished before the pharaoh died
  • and it had to be big."

Where you are building the second tomb you actually build a defective tomb it is too small and not BIG as was the requirments. Adding to it just makes it more defective and if the Pharaoh died halfway through one of the additions you would still get the issue outlined in one. So there is no perfect solution to the problem. 

 

Maybe a combination of the two approaches was taken then I think there would be a better match. This is not Agile or even Waterfall - But a merging of the two is always more successful. 

 
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 23, 2014
Intrigued by the concept of a converged infrastructure but worry you lack the expertise to DIY? Dell, HP, IBM, VMware, and other vendors want to help.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.