I'm a typical techie, totally lacking in vanity, not even sure what mirrors are for, so my only requirements for a hair cut are that it be cheap and fast. And so, once again I found myself at the local Hair Cuttery, chatting with the stylist as she did her $11 magic.
I'm fascinated with people, so I asked about her life and her job. A single mom, she was more or less abandoned by hubbie. The court-awarded child support arrived for a while, but petered out. Sometimes a check comes, more often not. She's had to raise two kids entirely on her own. Little education limited her prospects, but through heroics I can barely imagine she managed a short stint at the local Vo-tech and obtained her cosmetology license.
License? Turns out that in Maryland all hair stylists must pass a test and be certified. Now, the peril we're talking about is legions of Marylanders walking around with bad haircuts. No one will die or be injured, though perhaps teenaged girls will court suicide.
I thought about our profession. We're the people who built nuclear power plant controllers, avionics, life-critical medical instrumentation, and systems that control every aspect of huge industrial facilities.
License? Certification? Nah. If you can spell “C”, you've got a job. There's no need to understand failure mode analysis, DOD-178B certification, or FDA software requirements.
Can you crank some code, fast? If the answer is yes, your resume floats to the top of the pile.
Do you need to understand software methodologies, process engineering, CMM, PSP, agile development, or complexity metrics? Nope. Crank some code, fast.
Though I despise government regulations, I do think they're appropriate in some situations. Libertarians will claim that the market is the only true test of a product's worthiness. But wouldn't looser FDA guidance result in more dangerous medicines? The FAA's stringent requirements surely have led to safer aircraft. Automotive products are cleaner and safer now only because the car companies were dragged kicking and screaming into compliance with various laws.
The embedded world is largely unregulated, but our systems are getting more complex and ubiquitous. Malfunctions are on the upswing. We do know that as firmware complexity increases, errors will too. Though there are plenty of well-known ways to improve software most require spending more time and money on development. The curse of frenetic competition and our obsession with quarterly profits drives companies to focus more on shipping fast than on getting it right.
More regulation might make firmware like drugs: longer time to market, better quality, and a wider belief in the stability of the products.
Though I abhor the thought of certifying developers, and would probably leave the industry if this happened, is it inevitable?
I feel safe knowing that Maryland is the land of the elegant haircut, but I flinch every time a plane flies overhead.
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. He founded two companies specializing in embedded systems. Contact him at . His website is .
Commenting on one sentence in Brian Johns comments (see below). The ACM is still a “constituent society” of the Institute for Certification of Computing Professionals (ICCP) according to the ICCP web site.
Not sure of any of the proposed options. While I agree that most software systems suffer from inadequate requirements and design, I'm also aware that no-one has yet found a way to solve the Halting Problem. It means we have to be careful not only about how we design and make the code but about being sure we know what we want it to do, but having done all that to use rigorous testing on the product that contains it. Has no-one else noticed that a decent test rig is at least an order of magnitiude more complex than the code under test but the test rig is usually the most lashed-up piece of software in the department? I've also diagnosed an obscure software fault being due to bugs in the RTOS – so often we are dependent on our suppliers as well as our own wits. I suspect that the twin answers are rigorous product test and professional integrity, but I don't think you can quantify the latter and therefore I am unsure of any attempt to certify it.
There has to be a regulatory authority for the products which have complex embedded software in them – not one for those who develop that software. For example, the FAA certifies the air worthiness of aircraft. If the aircraft passes all the test parameters, doesn't it mean that the system as a whole, including the complex embedded software is working well?
I don't think having “certified” engineers will help improve the quality of software. What next? Certified designs? Certified algorithms?
Philips Software Centre
Certifation of individuals does not improve haircuts in Maryland and would not make embedded systems safer. Software designers would memorize some (probably useless) material to pass a certification test, and then promptly forget it. Managers would still hire the fastest coders and squeeze the development time to the minimum.
The only thing that would affect quality is if the documentation for software projects had to be reviewed and blessed by the government, as is the case in the medical industry. Then again that is precisely why I left the medical industry.
From your poll, the choices are:
- How do you feel about certification for developers?
- A terrible idea
- Self-regulation is the answer
- Let the IEEE form a regulatory body
- The Feds should step in
You are ignoring the obvious. Engineers who offer services to the public are licensed in all states and the District of Columbia (just like barbers and hairdressers, just the exams are a bit tougher). State licensure works for the professions. Use it.
Certification for software developers is a dumb idea that will validate 2nd-raters and lead to good people being rejected.
The argument about aircraft is invalid. Safety-critical systems are verified by a lot more than the certificates of the developers, or better be.
A massive problem in certifying developrs is in deciding what constitutes the required body of knowledge. Early efforts at doing this were abysmal, with 2nd rate academics using 10-year old textbooks. I don't believe much has improved.
The ACM considers the idea so dumb it is formally opposed to licencing of software engineeers, and pulled out of the IEEE's efforts.
If we had certification in 1990, we would probably still be using character mode screens and COBOL.
The fact that professional registration (including the pursuit of) has not taken hold in the software industry puzzles me. Developers use software to perform incredibly complex tasks and, yet, the “engineering” aspect of analysis and design is quite often treated like its an inconvenient annoyance or marginally useful. In contrast, traditional engineering fields, analysis and design is NOT an option. Don't do it right, there are real consequences both to the organization and to the practicing engineer.
Now contrast that with the practice of software “engineering.” It strikes me that achieving a “certification” or “registration” should, at the very least, be strongly encouraged or the absence thereof should be “career-limiting.” If the results of one of your polls (likelihood of code reaching spaghetti state) are any indication of the state-of-the-practice, it strikes me that “certification” or “registration” is warranted.