For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

By Jack Ganssle

Failure is an Option

Published 4/19/2005

The data is stark: according to the Standish Group’s Chaos report zero percent of software projects over $10m in size are deemed successful.

I guess the good news is that things can’t get worse.

Zero percent doesn’t mean zero, of course, but successes are in the noise.

There’s no indication how many of these 35,000 projects are embedded versus traditional IT-like software, but since the embedded industry gets no respect, it’s reasonable to assume few of the projects were embedded. Here’s more data:

  Successful Challenged Failed
Projects under $500k
38%
44%
19%
27%
52%
21%
Projects $3m - $6m
16%
55%
29%
Projects $6m - $10m
4%
57%
39%
Projects over $10m
0%
66%
34%

“Successful” means a project delivered mostly on-time, on-budget with most of the promised features. “Challenged” are those that were substantially over budget, quite late and had many features scrubbed. “Failed” are those that were cancelled or unused.

The data mirrors my observations of firmware development. Few 4Kb 8051 programs fail to live up to expectations. Scale that to 32 Mb of PowerPC code and the odds of getting anything working remotely like the marketing dweebs originally expected are small.

Especially horrifying is the number of abandoned projects. I don’t know how many development efforts were in each dollar ranking, but for guestimation purposes let’s assume the average size ran about $2m. The 21% of the 35,000 projects rated as failures equal some $15b in work tossed out the door, equivalent to about 100,000 squandered person-years of effort every year. And that’s just for the surveyed programs, which are a bare fraction of all software development going on world-wide in any given year.

We’re not doing well.

Something like half of the programs gave customers less than they’d been promised. An editorial in Windows magazine complained that they evaluated a number of shrink-wrapped programs… and 17 in a row did not live up to the promises on the box.

Few industries thrive when they alienate the customer. Software is different than most other products, of course, as consumers simply don’t know if the shiny widget seducing them from Wal-Mart’s shelves will actually work as promised - or is a lemon. How do you know if that DVD player doesn’t read older disks reliably? Or if the software shuts the engine down when the tank is under a third filled (as happened on a BMW)?

But the 'net is the great equalizer, and consumer sites which let readers rank products will eventually force vendors to provide products that meet – and exceed – the promises made in the glossy ads.

According to some sources firmware doubles in size every 10 months, which suggests that eventually even Brookstone’s smart coffee spoon’s code will eat all of the resources of a 500 MHz ARM with half a gig of Flash. But will it ever hit the shelves? Will it work correctly?

Marketing can take their share of the blame for exploiting the low-recurring cost of software by adding every conceivable feature to the simplest of products. Consumers are at fault, too, for their (uh, our) sheep-like pursuit of whatever Madison Avenue plasters across the billboards and TV screens.

But if we developers don’t adopt better processes to bring in big projects on-time with reasonable functionality, our jobs will be at risk.

What do you think? How do you get big systems out in a reasonable amount of time without sacrificing the bulk of the features?