Is Software Engineering?

Home : Writing : by Trevis Rothwell, June 2012

IMG_5621

One of the many frequent debates amongst software practitioners is that of, what do we call what we do? Is it computer science? Is it programming? Is it software engineering? Is it art? Is it craft? Is it digital cuisine?

I have come to think that any of these terms (and more) could conceivably apply to some aspect of software development. When we are waxing theoretical and doing hardcore algorithms analysis, perhaps we are computer scientists. When we are taking an existing software design (written by ourselves, or by someone else) and coding it up, perhaps we are programmers. When we are chopping bytes into nibbles and bits and tossing them into a frying pan, perhaps we are chefs.

But what of engineering? Civil engineering that produces suspension bridges and skyscrapers involves intense planning, stress-testing, and certified professional engineers staking their reputation on signing off that the work is good.

Has software development matured to the point where we could with a straight face deem what we do to be engineering? I believe, in some contexts, it has.

Serious Applications Make Serious Demands

In their Software Architecture Primer, authors John Reekie and Rohan McAdam make the case that not all software projects require the same level of scrutiny, no more than all physical construction projects do. If you're building a dog house, it may suffice to build it all off the top of your head, sawing wood into approximately-correct dimensions and hammering it together. A typical dog house simply does not need to endure much physical stress.

If you're building a house for people, then you enter into a whole new world of building things in accordance with housing code, and, housing code aside, common sense tells you that a 1500-square-foot residence is going to demand more planning and excellence of workmanship than a 5-square-foot dog house.

It is similar with software. If you're making a cheesy entertainment app for the iPhone, nobody really cares if it's poorly designed, unmaintainable, or flat-out doesn't work. At most, these issues could be a minor annoyance.

If you're building an email client, things get a little more serious. Users will depend on your software to perform a specific function, and while there are worse problems in life than undelivered mail, it makes sense that you would need to put more effort into making sure an email client works than a trivial mobile phone game.

What about software that runs financial institutions? It wouldn't be good if the money in your account just disappeared. What about software that controls medical equipment? It wouldn't be good if a patient's oxygen supply just stopped. What about software that controls jumbo jets? It wouldn't be good if hundreds of passengers slammed into a mountain.

We can easily look at most software that we encounter and note firstly that it's not very robust, and secondly that it doesn't need to be. Microsoft Word crashes and we lose a half-hour of writing; it's bothersome, not catastrophic. But there's also a lot of software that we might not even immediately think of as being software that we depend on to take care of our money and even our lives, and that software had better work right.

Software Considerations in Airborne Systems and Equipment Certification

IMG_5441

I have not worked on financial or medical software, but I have worked on projects for several aircraft. Most of those projects were implemented to the guidance demanded by the Federal Aviation Administration, that is, the document DO-178B, Software Considerations in Airborne Systems and Equipment Certification.

DO-178B defines five levels of criticality of software that could be used onboard an aircraft; to summarize:

For each level, DO-178B prescribes guidance on matters such as:

All of those things must be reviewed and signed off on by the development team, as well as reviewed by a third-party quality assurance process that audits the work to make sure that the planning was done in accordance with DO-178B and the implementation was done according to plan. The entire work must also be reviewed and signed off by a certification liaison working on behalf of the FAA.

Elsewhere in the process, tools used for development have to be checked out and approved for use; anything ranging from compilers to third-party libraries and operating systems to in-house software that assists with verification is subject to scrutiny.

For anything above Level E software, it's a pretty intense process, and the higher up you go in criticality, the more intense the process becomes, with stricter demands placed on your planning, implementation, and verification.

In short, avionics software is not a weekend hack.

True Software Engineering?

With reams of requirements, bastions of verification procedures, reviews and sign-offs and audits at every step of the way, I feel comfortable deeming software projects such as avionics systems to be true software engineering. The end-product is not just a compiled application, but ample supporting documentation and assurance that the application behaves as intended.

To be sure, such practices would be overkill and a huge waste of time for, say, most iPhone applications. Lots of everyday user-facing software simply does not get enough benefit from laborious planning and verification to make it worthwhile. But is it still engineering?

That's debatable. However, just as DO-178B process itself includes a spectrum of levels of software, perhaps it would be fair to view software engineering as a whole on a spectrum. Trivial software needs only unrestricted coding in order to be acceptable; that is, just whatever it takes for the software to exist. More serious, yet not life-preserving, applications would benefit from planning and testing and documentation, but the extent of such would be far less than is needful in avionics.

Once the case is made that true software engineering can exist, we might go on to say that all software development is an engineering effort, only with varying degrees of criticality, and thus, varying degrees of assurance of functionality.

Even at DO-178B Level A projects though, with all of their intense demands, the resulting software is still not mathematically proven to be correct. But is anything in the real world of civil engineering mathematically proven to be correct?

tjr@acm.org