原创 Software Engineering versus "real" engineering

Are we engineers? In some states in the US that title is restricted to those who pass professional competency tests.

The New Oxford American Dictionary (2^nd edition, 2005) defines the noun "engineer" thusly: A person who designs, builds or maintains engines, machines, or public works.

The Shorter Oxford English Dictionary (6^th edition) provides a number of definitions; the one most closely suited to our work is: An author or designer of something; a plotter.

Neither really addresses what we do, though I have to admit liking "a plotter" as it paints us with an air of mystery and fiendishness.

In a provocative piece in the March 2009 issue of the Communications of the ACM ("Is Software Engineering Really Engineering?" by Peter Denning and Richard Riehle) the authors wonder if software development is indeed an engineering discipline. They contend that other branches of engineering use standardised tools and metrics to produce systems with predictable outcomes.

They state about software: "[no process] consistently delivers reliable, dependable, and affordable software systems. Approximately one-third of software projects fail to deliver anything, and another third deliver something workable but not satisfactory."

That huge failure rate is indeed sobering, but no other discipline produces systems of such enormous complexity. And we start from nothing. A million lines of code represents a staggering number of decisions, paths, and interactions. Mechanical and electrical engineers have big catalogs of standard parts they recycle into their creations. But our customers demand unique products that often cannot be created using any significant number of standard components.

At least, that's the story we use.

I hear constantly from developers that they cannot use a particular software component (comm stack, RTOS, whatever) because, well, how can they trust it? One wonders if 18^th century engineers used the same argument to justify fabricating their own bolts and other components. It wasn't until the idea of interchangeable parts arrived that engineering evolved into a profession where one designer could benefit from another's work.

Today, mechanical engineers buy trusted components. A particular type of bolt has been tested to some standard of hardness, strength, durability and other factors.

In safety-critical applications those standard components are subjected to more strenuous requirements. A bolt may be accompanied by a stack of paperwork testifying to its provenance and suitability for the job at hand. Engineers use standardised ways to validate parts. The issue of "trust" is mostly removed.

Software engineering does have a certain amount of validated code. For instance, Micrium, Green Hills and others offer products certified or at least certifiable to various standards. Like the bolts used in avionics, these certifications don't guarantee perfection, but they do remove an enormous amount of uncertainty.

I'm sure it's hugely expensive to validate a bolt. "Man-rated" components in the space program are notoriously costly. And the expense of validating software components is also astronomical. But one wonders if such a process is a necessary next step in transforming software from art to engineering.