For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

By Jack Ganssle

Making Software Engineering Engineering

Summary: Are there provable theoretical underpinnings behind software engineering?

Michael Linden alerted me to an article (http://www.ddj.com/architect/222001342) in Dr. Dobbs (alas, now just a ghostly web presence rather than a print pub) wherein the author expounds on the hopes of a significant group of well-known people to define an epistemology of software engineering. Links are provided to other quite interesting articles that describe the need to develop a theory of software engineering.

A number of prestigious signatories have created the SEMAT (Software Engineering Method and Theory community) (http://www.semat.org), which is an attempt to figure out the fundamentals of our profession. To quote from the DDJ article: "Software engineering is gravely hampered today by immature practices. Specific problems include:  The prevalence of fads more typical of fashion industry than of an engineering discipline.  The lack of a sound, widely accepted theoretical basis.  The huge number of methods and method variants, with differences little understood and artificially magnified.  The lack of credible experimental evaluation and validation.  The split between industry practice and academic research. "We support a process to re-found software engineering based on a solid theory, proven principles, and best practices that:  Includes a kernel of widely-agreed elements, extensible for specific uses.  Addresses both technology and people issues.  Is supported by industry, academia, researchers and users.  Supports extension in the face of changing requirements and technology. " There has long been a debate about this field. Is it engineering? Art? One would think that if the former, there would be some principles grounded in the sciences. EEs rely on basic, provable, physics like E=IR and Maxwell's equations. EEs can compute solutions and prove correctness. That's not generally true for software. SEMAT wants to change the rules and push real engineering into the software environment. I'm hugely supportive of that goal.

And skeptical, as well.

Perhaps there is some theoretical underpinnings to software engineering, some science from which we can derive the one correct way to write code. Today all we have are aphorisms and ideas, some grounded in anecdotal evidence, some cautions of approaches to avoid. Either there is no basic science we can draw upon, or we're akin to 15th century alchemists, practicing our art while awaiting the Newtons, Boyles and Einsteins to lift the veil of ignorance. I hope it's the latter but fear it's the former.

We do have an important body of knowledge of practices that often work and those that don't. None are grounded in any sort of theory and all seem as arbitrary as the rules behind quantum mechanics.

The SEMAT folks are creating a "kernel" of knowledge from which their research will proceed. The kernel was formed from examining many different software methodologies and finding the common elements. That's like excavating fragments of bones to piece together a complete dinosaur skeleton, and is quite worthwhile. I doubt, though, that the approach can lead to an approach to engineering that has the mathematical rigor that forms the core of most other engineering fields.

Published December 16, 2009