For novel ideas about building embedded systems (both hardware and firmware), join the 27,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. It takes just a few seconds (just enter your email, which is shared with absolutely no one) to subscribe.
By Jack Ganssle
Software engineering is not a discipline. Its practitioners cannot systematically make and fulfill promises to deliver software systems judged by their customers as usable and dependable, on time and fairly priced. The illusion that software engineers possess a discipline has produced the major breakdown called the software crisis.
This quote, from a 1992 paper written by Peter Denning and Pamela Dargan (http://www.virtualschool.edu/mon/SoftwareEngineering/PDenningDisciplineOfDesign.html) completely ticked me off the first time I read it. The authors essentially claim that we're neither capable nor professionals.
Then I read it again. Well, yeah, we can't actually fulfill promises, the software usually isn't on-time, yup, and it's often not all that useable.
Maybe they have a point. Are we professionals?
Dictionary.com defines the noun form of "professional" as a person following a profession, especially a learned profession. Though the definition is annoyingly recursive, the sense is that professionals are the highly educated wizards who routinely solve tough problems. Like an engineer, right?
Well, maybe not. Compare us to other professionals. Doctors, for instance - most people endow those authorities with the "professional" moniker. Sure, they have an enormous amount of education, but perhaps the defining aspect of their career, the one that truly merits the word "professional," is their on-going education. Somehow doctors manage to incorporate the vast amounts of new research into their daily practices. Can you imagine being a doctor who learned medicine in the 1940s, before penicillin, who continued to practice through the 50s, 60s, 70s and 80s using the same skills he learned so long ago?
He'd be considered a butcher.
How about teachers? I've always considered them professionals. Despite the low pay teachers in most states must take a certain number of continuing education credits every year or two to maintain their certifications.
Plumbers, hair stylists, electricians and numerous blue collar jobs require certification and licensure.
We design nuke controllers, avionics, implanted medical devices, and if you can spell C, you've got a job.
Today few states have any sort of certification requirements for embedded developers, though some locales restrict the use of the title "engineer." But, for better or worse, certification is surely coming.
Embedded is a stealth industry today. Consumers might be vaguely aware of the buried processor but give it little mind-share. As electronics becomes ever more pervasive, and as critical systems suffer more failures (for instance, pacemaker recalls due to firmware problems are going up) legislators will wield the usual blunt ax.
We can - we must - stave off this impending revolution that will hit all of our careers, but only by acting more professional, by actively soaking up new ideas, concepts and approaches to building systems.
All of us are smart folks who are experts at learning new skills, like how to use a different processor or building faster ISRs. But we too often fail at finding and embracing new processes that can help us make better products.
For example - are you familiar with the CMM? In my opinion every professional software developer should be an expert at the Capability Maturity Model. The usual chorus will loudly protest here. Sure, the CMM is bloated and flawed, and even in the best of cases is impossible other than in large organizations. But it contains useful and essential ideas that we can incorporate into our daily work.
Have you read Watts Humphrey's A Discipline for Software Engineering. and done the homework? It's a tough slog but the benefits are amazing. Though no silver bullet, the mechanisms Humphrey diagrams give big benefits to individual programmers.
How about any of the books about agile methods? Have you adopted any of the concepts? Though a few in the agile community makes whacky claims, and I remain unconvinced about some of the practices, there's a wealth of valuable ideas that will lead to better systems.
Are you a member of the ACM or IEEE? Both offer a wide range of useful (and some deadly dull) journals.
Books (here's my reviews of some: http://www.ganssle.com/bkreviews.htm), classes, conferences, magazines and on-line resources abound. Are you truly engaged with your profession?
If not. why not?