> As the 120-ton space shuttle sits surrounded by almost 4 million
> pounds of rocket fuel, exhaling noxious fumes, visibly impatient
> to defy gravity, its on-board computers take command. Four
> identical machines, running identical software, pull information
> from thousands of sensors, make hundreds of milli-second
> decisions, vote on every decision, check with each other 250
> times a second. A fifth computer, with different software,
> stands by to take control should the other four malfunction.
> [...] But no human pushes a button to make it happen, no
> astronaut jockeys a joy stick to settle the shuttle into orbit.
> The right stuff is the software. The software gives the orders to
> gimbal the main engines, executing the dramatic belly roll the
> shuttle does soon after it clears the tower. The software
> throttles the engines to make sure the craft doesn't accelerate
> too fast. It keeps track of where the shuttle is, orders the
> solid rocket boosters to fall away, makes minor course
> corrections, and after about 10 minutes, directs the shuttle into
> orbit more than 100 miles up. When the software is satisfied with
> the shuttle's position in space, it orders the main engines to
> shut down -- weightlessness begins and everything starts to
> But how much work the software does is not what makes it
> remarkable. What makes it remarkable is how well the software
> works. This software never crashes. It never needs to be
> re-booted. This software is bug-free. It is perfect, as perfect
> as human beings have achieved. Consider these stats : the last
> three versions of the program -- each 420,000 lines long-had just
> one error each. The last 11 versions of this software had a total
> of 17 errors. Commercial programs of equivalent complexity would
> have 5,000 errors.
> Bill Pate, who's worked on the space flight software over the
> last 22 years, says the group understands the stakes: "If the
> software isn't perfect, some of the people we go to meetings with
> might die.
> Virtually everything -- from the international monetary system
> and major power plants to blenders and microwave ovens -- runs on
> software. In office buildings, the elevators, the lights, the
> water, the air conditioning are all controlled by software. In
> cars, the transmission, the ignition timing, the air bag, even
> the door locks are controlled by software. In most cities so are
> the traffic lights. Almost every written communication that's
> more complicated than a postcard depends on software; every phone
> conversation and every overnight package delivery requires it.
> Software is everything. It also sucks.
> "It's like pre-Sumerian civilization," says Brad Cox, who wrote
> the software for Steve Jobs NeXT computer and is a professor at
> George Mason University. "The way we build software is in the
> hunter-gatherer stage."
> John Munson, a software engineer and professor of computer
> science at the University of Idaho, is not quite so generous.
> "Cave art," he says. "It's primitive. We supposedly teach
> computer science. There's no science here at all."
> Software may power the post-industrial world, but the creation of
> software remains a pre-industrial trade. According to SEI's
> studies, nearly 70% of software organizations are stuck in the
> first two levels of SEI's scale of sophistication: chaos, and
> slightly better than chaos. The situation is so sever, a few
> software pioneers from companies such as Microsoft have broken
> away to teach the art of software creation ( see "Drop and Code
> me Twenty!" )
> Mark Paul, a senior member of the SEI technical, says the success
> of software makes its weaknesses all the more dramatic. "We've
> developed software products that are enormously complex and
> enormously powerful. We're critically dependent on it," says
> Paul. "Yet everyone complains how bad software is, with all the
> defects. If you bought a car with 5,000 defects, you'd be very
> In this software morass, the on-board shuttle group stands out as
> an exception. Ten years ago the shuttle group was considered
> world-class. Since then, it has cut its own error rate by 90%.
> To be this good, the on-board shuttle group has to be very
> different -- the antithesis of the up-all-night,
> pizza-and-roller-hockey software coders who have captured the
> public imagination. To be this good, the on-board shuttle group
> has to be very ordinary -- indistinguishable from any focused,
> disciplined, and methodically managed creative enterprise.
> In fact, the group offers a set of textbook lessons that applies
> equally to programmers, in particular, and producers, in general.
> A look at the culture they have built and the process they have
> perfected shows what software-writing must become if software is
> to realize its promise, and illustrates what almost any
> team-based operation can do to boost its performance to achieve
> near-perfect results.
> Software for Grown-Ups
> "Shipping hell continued today. Grind, grind, grind. We'll never
> make it. Have I said that already? Why do we always underestimate
> our shipping schedules? I just don't understand. In at 9:30 AM;
> out at 11:30 PM Dominos for dinner. And three diet Cokes."
> No, it's not the on-board shuttle group. It's Douglas Coupland's
> "Microserf's," a true-to-life fictional account of life in the
> software-fast-lane. And it's the dominant image of the software
> development world: Gen-Xers sporting T-shirts and distracted
> looks, squeezing too much heroic code writing into too little
> time; rollerblades and mountain bikes tucked in corners; pizza
> boxes and Starbucks cups discarded in conference rooms; dueling
> tunes from Smashing Pumpkins, Alanis Morrisette and the Fugees.
> Its the world made famous, romantic, even inevitable by stories
> out of Sun Microsystems, Microsoft, and Netscape.
> "Our requirements are almost pseudo-code," says William R.
> Pruett, who manages the software project for NASA. "They say, you
> must do exactly this, do it exactly this way, given this
> condition and this circumstance."
> This careful design process alone is enough to put the shuttle
> organization in a class by itself, says John Munson of the
> University of Idaho. Most organizations launch into even big
> projects without planning what the software must do in
> blueprint-like detail. So after coders have already started
> writing a program, the customer is busily changing its design.
> The result is chaotic, costly programming where code is
> constantly being changed and infected with errors, even as it is
> being designed.
> "Most people choose to spend their money at the wrong end of the
> process," says Munson. "In the modern software environment, 80%
> of the cost of the software is spent after the software is
> written the first time -- they don't get it right the first time,
> so they spend time flogging it. In shuttle, they do it right the
> first time. And they don't change the software without changing
> the blueprint. That's why their software is so perfect."