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'll 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 greatly 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 nontrivial. 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?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .
I agree. I do embedded software tools consulting and most engineers that I come across have zero time to even do a tool eval, much less bring a new methodology into their company. I have worked with a lot of automotive companies and these companies seem interested in the UML buzz that is going on, as an example, but they have zero idea how to apply a UML tool to their applications.
– Scott Ranville
Am on ur side. U've made the point succinctly. In my 6 years of writing embedded code for DSP systems I did not find a vendor who gave me the numbers that made me interested in using methodology tools combined with the pressure to roll the product out in a very short time.
– Oswald Correya
The problem is that vendors like Rational Rose, while selling their wares, are neverable to prove, in a real project sample (at least a medium size), that their methodology actually performs innumbers or matrix. All they do are printing facny diagrams, which, to firmware engineers, don't mean a thing.
– Henry Khoo
Developers on small projects (< 128k,="" and="" even="" less="" ram)="" who="" think="" like="" i="" do="" assume="" -="" rightly="" or="" not="" -="" that="" such="" tools="" will="" consume="" too="" many="" resources,="" and="" will="" cost="" too="" much="" in="" terms="" of="" control="" over="" the="" software="" architecture.="" we="" believe="" our="" unique="" little="" platforms="" will="" refuse="" to="" conform="" to="" a="" vendor's="" template,="" or="" behave="" as="" well="" as="" the="" simple,="" sterile="" demonstrations="" we="" are="" shown.="" you="" are="" right="" that="" some="" specific="" testimonials="" from="" people="" whose="" systems="" resemble="" our="" own="" would="" be="" far="" more="" convincing.="">
– David M. Tomer
Just fyi – adding a little to the “noise” of process/tool users in embedded systems:
I have worked on a massively parallel embedded system (radar) for a well-known defense contractor, and we wereusing a UML tool on the project. The company as a whole has embraced CMM and later CMMI, largely due togovernment pressure. But I don't think of CMM or CMMI as development processes – rather as classifications ofprocess maturity or as metaprocesses – so it may not be fair to claim “market share” for them in the same senseas a better defined, hands-on process like USDP. Finally, some agile practices have also been getting attentionhere.
Still, I wouldn't say that we are using tools to promote higher productivity, but rather higher quality andeasier legacy maintenance.
My company is different from most in some respects – it's relatively big and so has more resources, it works onrelatively large and complex embedded systems, and it's a government contractor. All of these factors tend topromote “process creep” and even process overload.
– John Hopkins
I was recently assigned to a project to develop the software for a keypad readerthat connects to a CAN bus. I was given the “tried and true” A51.exe and L51.exe, DOS assembler/linker. OnceI get the code written, I put the hex file on a floppy and carry it over to another computer which has DOS forthe OS, and program an EEPROM using a programmer connected to the printer port. This is because “we can'ttrust flash devices”, so we use the method that has worked for the past 10 years.
Once I can get my company into the 21st century, then maybe I can get a C compiler for a flash based 8051.Then, maybe, I can start looking at methodology tools.
– Edward Handrich
I agree with Jack. I've gotten pushback from management on getting licenses for PC-lint(we do C++ and freeware Splint doesn't). There's been lukewarm response on process improvement as well. Workingsmarter seems to be most welcome only when its cheap or free. We need tangible 'user stories' with costbenefit analysis and amortization data before management bites!
– Sean Thomson
Jack replies: Sean – wow – and PC-Lint is only $239/copy! Yet it finds many bugs so cheaply. Ifwe're not allowed to spend that kind of minimal dough, we'll be like a caveman, working with bone knives.
I think vendors don't provide numbers because a)they don't have them and, b) theseasoned, grizzled embedded programmers promptly ignore them anyway. Why? Because, unlike a big IT project,embedded projects are always unique and often cutting edge. The vendor's case study is usually irrelavent to mysituation. In addition, most methodologies don't scale down well to deeply or medium embedded systems. Even ifI've got loads of memory and CPU for one project, my 5 spin-off devices are going to be bare bones. Forget thespreadsheet and 5 year ROI. Give me a tool that saves me time this week. I'll know it when I see it.
– Michael Juran
Tools for embedded systems are very expensive, nine times out of ten it best to go withthat have no eval time, for me my self I spend zilch for any tools as long it is free(linux), i thinkdevelopers should merge to linux and stay with a standard tool for embedded systems(ecos)…
– fred barnes
You hit the nail on the head with “vague tales of success.” To be quite honest, much ofwhat I've come across are “vague tales of methodology” — these approaches fill your head with new buzzwordsbut often don't relate them to real world problems. Sure, they can verify a state machine with code that fitson one page — but how about one with dozens of states requiring multiple files of code to implement? I *have*read some of the PSP books, but my main gripe with Humphrey is that his baseline process (withoutcustomization) only works on object-oriented software — not assembly!
– Greg Nelson
I totally agree with all the problems you've listed Jack.
Do you think our largest problem is the relatively small number of embedded programmers? Either there's lessof us, or as you've said, we're too busy to pull our heads out of the sand and network with each other.
On a popular, high quality SW forum, there's hardly any embedded talk, mostly application software. The fewembedded folks there are, are rather quiet. I'm sure if they started an embedded topic, most people wouldn'tknow what they were talking about.
An embedded fellah who has a blog says he's found a total of only 2 other blogs dedicated to embedded issues,and one of them is inactive.
Not the mention the lack of books on embedded software. To be sure, there are some gems out there, but there'sso few compared to app software.
So perhaps our problem is that we're too small a market (either real or perceived) for companies to make aneffort to cater to us?
– Vinh Pham
Someone at my company actually got management to buy some UML tools and a weeklongtraining course for ten engineers. We took it, learned it, and then nobody used it. Why not? No ramp-up. Nopractice. No procedural buy-in. I think the Powers that Be expected us to become instant experts after thetraining. None of us had time to back-enter our current projects and by the time new projects came around(where the UML tool could be used from the outset), interest had lapsed.
– Daniel Singer
I've been doing embedded for many years. I've taken the PSP course, and am convinced of the value of PSP, and that it can be adapted to any type of software development. When I attempted to sell it to my management, in two different companies, the response was barely lukewarm. Managers are unwilling to spend the resources needed to train the developers, and they're unwilling to support them in improving process, lip service to the contrary notwithstanding.
– Phil Schmidt
We have successfully implemented and shipped a product, where we used UML methodologies to design, model, implement, and debug a small embedded system.
This was an effort with some 10+ firmware programmers that stretched over a couple of years, and at first there wasn't a lot of support for using 'high-level' methodologies, but having tried this before we stuck them in there – and when we started meeting deadlines and having really fast turnaround time on bug reports, we could start selling the idea of UML.
We are now trying to use Rhapsody vertically, all the way from Marketing and use-case studies, to the implementation level.
The proof is in the pudding, and I find real-time embedded systems to be the best show-case for managing complexity with better methodolgy.
– Soren Juelsgaard
Up to a certain point complexity can reside inside one's head. When you get overwhelmed by complexity, its time to use the proper tools.
64k of assembly may be still mastered by one individual while 16 MByte of C++ definetly are not. In between there is the grey zone where engineers often beg their management [who grew up on 8-bits, at best] without much success for adequate [expensive] tools and some degree of methodology.
In case you're doing human-safety related embedded systems, the lawyers may come to your help.
After a visit to Europe's largest embedded show in Nuremberg, there are a number of methodology vendors, but, helas, all seem to be unable to prove their case with hands on testimonies or numbers.
Most embedded world still sees the managment of complexity somewhere between belief and witchcraft. This will change with growing use of 32-bits.
– Bernhard, Kockoth