By Jack Ganssle

Schedules and Budgets

Published 4/08/2004

The boss needs a schedule for the new project. By Friday. Somehow engineering has to design and decompose a system containing perhaps thousands of functions in three days.

That's impossible, of course, so we're lucky to even rough out any design before taking stabs at estimating hours. "Uh, that display handler looks pretty big; better figure three months on it alone."

50 years of software engineering has taught us that people can't estimate a function larger than around 50 lines of code with any accuracy. The bigger the chunk the worse our guess. Unless you can estimate by analogy - by comparing the new system to one that's quite similar, one for which you've kept productivity records - accurate scheduling means first doing a detailed design, down to the function level.

Though we complain and demand more time to create a meaningful estimate, in most cases the boss helpfully provides the end date. "We need it by the show in June."

"Yes, massa," we humbly submit, and wander off to our cubicles to fire up Microsoft Project. Following our unerring instinct for job preservation the entire department jiggles triangles around, all the time leaving the most important one - the end date - immovably welded to June 1. What are these people doing? Why, they're creating a schedule that looks somewhat believable, at least in the early phases of the project, even though not one of them has the slightest faith in any of the estimates.

Like the teenager who hides Friday's report card to avoid ruining the weekend, they're postponing the day of reckoning, hoping for a miracle. Mary appears at Lourdes more often than software projects experience a wondrous recovery.

Even when the boss doesn't assign a capricious date our estimates are woefully off since software is intrinsically tough to predict. Some wise developers, scarred from repeated battles in the firmware wars, multiply their best guess by 2. It's a cynical approach that demeans our professionalism. Yet it's often unerringly accurate.

More accurate than I had imagined. Last month the GAO testified before Congress about the state of two big fighter aircraft programs (http://www.house.gov/hasc/openingstatementsandpressreleases/108thcongress/04-03-25li.pdf). Both the F/A-22 and Joint Strike Fighter (JSF) are behind schedule and appallingly over budget. 1986 projections put the F/A-22's development costs at $12.6 billion. Today the GAO projects $28.7 billion. The schedule has grown from 9.4 years to an estimated 19.2 today.

If instead of an army of accountants stifled by unending Congressional inquiries, a grizzled old embedded systems developer had taken the original projections and simply doubled them - per the rule of thumb - he would have been off by only 12% in dollars and 2% in time.

With 1.3 million lines of code buried in the fighter it makes sense that an embedded developer should estimate the F/A-22 instead of CEOs and financiers. After all, that code is responsible for a big chunk of the slippages. The avionics were originally required to run for 20 hours between crashes. Such a lofty goal proved elusive so, adopting the delightful acronym MTBAA (Mean Time Between Avionics Anomalies), the DoD now specifies an MTBAA of 5 hours.

Problem is, as of today the code runs only 2.7 hours between crashes. Windows 3.1 looks good in comparison.

1996 estimates placed development costs of the JSF at $24.8 billion. Today the guess is $44.7b. Dare we say that a number near $50b, twice the 1996 projection, will be accurate?

The Agile community, drawing on Gilb's Evolutionary methods, recognizes the futility of scheduling. They iterate development, while constantly updating the delivery estimate. Original numbers are not much better than guesses, but those estimates refine as the product evolves.

It seems laughable, but the final schedule is rock solid on the day the product is ready. Which is exactly the same situation in big systems procurement, like the F/A-22 and JSF.