Published 2/19/07

Accepted wisdom is that most of the cost of software lies in its maintenance. As far back as the 70s (http://elearning.tvm.tcs.co.in/SMaintenance/SMaintenance/6.htm) various researches pegged it at 40-80% of the total lifecycle cost, with most of the papers leaning towards the higher numbers.

Nothing seems to have changed; Bertrand Meyer (in Objected Oriented Software Construction) claimed that in 1997 70% of software costs belong in the maintenance phase.

But is this true for firmware?

To my knowledge there are no studies on the subject; indeed, embedded systems are the stealth segment of software which simply doesn't garner the research applied to IT projects. So all we can do is speculate. But if that astonishing 70% number did apply to our projects, the cost implications are staggering.

Embedded code is inherently different than that living in the world of a PC. Despite `net-based reflashing that some - not many - products support, for most firmware a software upgrade is very costly. The car must come back to the dealer, or an instrument has to be returned to a repair depot. One could argue that these costs change the nature of the code; that the expense of doing an upgrade is such that firmware engineers inherently build better code.

In fact, that's my definition of an embedded system: a computer-based application with a very high quality bar. If the PC crashes it's not a big deal, but having to stop every 50 miles to reset the car computer is completely unacceptable.

Meyer quotes a study by Lientz and Swanson finds that 42% of maintenance costs stem from changes in user requirements. My sense is that there's little of that in the embedded space. MP3 players neither get recalled for bug fixes, nor are a stream of continuing software releases that improve functionality available. Instead, vendors launch a new version of the product, one that has a raft of newer, cooler features. The previous version's hardware and software is obsoleted.

That's very different than the PC, where on might use versions Word for years, contributing to Microsoft's bottom line via a never-ending series of upgrades rather than replacements.

Perhaps in the embedded world maintenance do to changing requirements is really expensed as new product development.

Lientz and Swanson claim 18% of maintenance costs come from changes in data formats. That smells like a problem in the info-processing world than in firmware. 21% are due to bug fixes, a plague shared by all programmers, and 6% from hardware changes. One would think that is entirely in the embedded domain.

Though I do see embedded products that have been in service and continually maintained for decades, most of our products don't resemble those gigantic business apps that have kept legions of aging COBOL programmers employed.

What do you think? How much of your budget goes to ongoing maintenance?