By Jack Ganssle

More on Certification

Published 9/06/2005

In the August issue of the Communications of the ACM ("Why the Software Industry Needs a Good Ghostbuster") Jeanette Nasem Morgan argues that software developers should be certified before being allowed to write commercial code. She complains that most other professionals already have certification processes in place. so why don't we? That muddled reasoning hardly, in my view, justifies a wholesale revamping of the engineering profession.

She worries that the tsunami of well-known software failures means we need some sort of Generally Accepted Software Engineering Practices, mirroring those adopted by CPAs and other professions.

And that's the problem.

There is no body of generally accepted software engineering practices. IEEE pushes the Software Engineering Body of Knowledge (SWEBOK - find it at http://www.swebok.org/), a summary of practices that simply don't align with what most developers actually do. The IEEE offers the Certified Software Development Professional (CSDP) certification which is mostly based on practices outlined in the SWEBOK.

The Software Engineering Institute's Capability Maturity Model is a well-known, lightly-used process that can yield good code. My informal survey of the embedded space shows that under 2% of companies are CMM certified at any level. And many certified outfits don't actually practice what the CMM preaches.

The SEI also pushes the Team Software Process (TSP) and Personal Software Process (PSP), nice ideas only rarely employed in the embedded space.

Today there's a big backlash against heavyweight processes like the CMM. Now it's all about being agile, and an alphabet soup of agile methods have sprung up. Some of the practices are much like those embraced by the SWEBOK and by the CMM. Others are orthogonal. There's little question agile methods are gaining acceptance, yet they're barely mentioned in the SWEBOK and are ignored by the CMM, PSP and TSP.

Other standards attempt to control development in different ways. MISRA constrains the use of C in motor vehicle applications. The FAA, FDA, and Federal Elections Commission all have very different standards that all aim to ensure safe software.

We have many - too many - standards and development methodologies. Though I doubt there will ever be a one-size-fits-all approach the plethora that exists today shows the immature state of this very young field. One reason certification works for CPAs is that there's really only one way to balance the books. Learn that, pass a test, and you're judged competent.

I have little doubt that software certification is coming. This is the only industry where we continue to get away with shipping products with known defects. Sooner or later people will stop smoking and all the asbestos will be safely buried somewhere, so the lawyers, looking desperately for a new source of revenue, will go after us. Insurers fed up with litigation payouts will demand that developers be certified or licensed in some manner.

But let's hope that doesn't happen till we can agree on the "right" way (or ways) to build software.

What do you think?