By Jack Ganssle

A Value Proposition

In the embedded space, UML has a zero percent market share.

In the embedded space, the Capability Maturity Model (CMM) has a zero percent market share.

The Shlaer-Mellor process tags right along at zero percent, as does eXtreme Programming, SCRUM, Feature-Driven Development, and every other methodology you can name.

Personal Software Process? Zilch. Design patterns? Nada.

(To be fair, the zero percent figure is my observation from visiting hundreds of companies building embedded systems and corresponding with thousands of engineers. To my knowledge no one has done a survey of embedded developers on this subject. And, to be fairer still, when I say zero percent, I mean tiny, in the noise. No doubt an army of angry vendors will write in protesting my crude approximation, but I just don't see much use of any sort of formal process in real embedded development).

There's a gigantic disconnect between the typical firmware engineer and methodologies. Why? What happens to all of the advances in software engineering?

Mostly they're lost, never rising above the average developer's horizon. Most of us are simply too busy to reinvent our approach to work. When you're sweating 60 hours a week to get a product out the door it's tough to find weeks or months to institute new development strategies.

Worse, since management often views firmware as a necessary evil rather than a core competency of the business they will invest nothing into process improvement. The truth is that adopting any new methodology (with the possible exception of the Personal Software Process) takes boatloads of time and money.

But with firmware costs pushing megabucks per project even the most clueless managers understand that the old fashioned techniques (read: heroics) don't scale. Many are desperate for alternative approaches. And some of these approaches have a lot to offer; properly implemented they can great increase product quality while reducing time to market.

Unfortunately, the methodology vendors do a lousy job of providing a compelling value proposition. Surf their sites; you'll find plenty of heartwarming though vague tales of success. But notably absent are quantitative studies. How long will it take for my team to master this tool/process/technique? How much money will we save using it? How many weeks will it shave off my schedule?

Without numbers the vendors essentially ask their customers to take a leap of faith. Hard-nosed engineers work with data, facts and figures. Faith is a tough sell to the boss.

Will UML save you time and money? Maybe. Maybe even probably, but I've yet to see a profit and loss argument that makes a CEO's head swivel with glee. The issues are complex: tool costs are non-trivial. A little one-week training course doesn't substitute for a couple of actual practice projects. And the initial implementation phase is a sure productivity buster for some block of time. Ditto for the rest of the acronym soup of methodologies listed in the poll.

Developers buy tools that are unquestionably essential: debuggers, compilers, and the like. Few buy methodology and code quality products. I believe that's largely because the vendors do a poor job of selling - and proving - their value proposition.

Give us an avalanche of successful case studies coupled with believable spreadsheets of costs and time. Then, Mr. Vendor, developers will flock to your doors, products will fly off the shelves, and presumably firmware quality will skyrocket as time-to-market shrinks.

What do you think? Turned off - or on - by methodology tools? Why?