A Software Engineer works with software systems of significant scope or importance and a a professional Engineer works in areas that may affect public welfare, so a professional software engineer must work with software systems that may affect public welfare. Some examples of such systems include:

  • Banking (e.g., ATMs, point of sale systems, electronic transfers, online banking)
  • Infrastructure (e.g., the electric grid, railroad switches, traffic lights)
  • Medical devices (e.g., pacemakers, insulin pumps)
  • Home automation (e.g., smart thermostats, nanny cams)
  • Automobiles (a typical modern car has 10 computers)
  • Industrial automation and process control (mechanical assembly, food or chemical production, or even power generation)

A structural engineer evaluating the plans for a bridge uses material science to determine if there is enough steel and concrete to support the weight of the vehicles that are expected to pass over the bridge. A civil engineer can calculate whether a theatre has enough emergency exits for all the patrons. So, what does a software engineer look for in assessing the safety of software or a software-enabled device?

Critical software should be designed not just thrown together. You may put together a quick spreadsheet to determine if you can afford a kitchen renovation, but the firmware in your gas stove requires more care. A design should guide the implementation and accurately describe the system after it is built. Often this design explicitly states what the system cannot — or is not designed to — do and these constraints and exclusions are important.

It is important to use appropriate components to build the software. You wouldn’t build a bridge out of modeling clay and you shouldn’t build critical software with a weak language or function library.

Software code is a written creative work and it needs to be reviewed. This is very much like the process of editing books or magazine articles. It’s foolish to think that an author can produce a flawless work of prose or that a programmer can produce a flawless program. Even a single review is often insufficient to catch all errors so the level of scrutiny needs to be appropriate to the application. You won’t hire a technical editor for your text messages but you might have several people look over your PhD thesis.

Software that we rely on needs to be tested by a testing specialist. It is insufficient for the programmer to run through some use cases that he or she thinks represent typical scenarios. The coffeemaker most likely has a UL label indicating that the design has been tested extensively to make sure it is safe for residential use. Similarly, software can be professionally and independently tested. Whether that testing is by a separate test group in the programmer’s company or by an outside lab will vary based on the safety requirements.

In many states, automobiles have to undergo periodic safety inspections. A car won’t run forever. Brakes and headlights and other critical parts age and your car needs maintenance to remain safe. The inspection, in part, ensures that such maintenance is not neglected. Software, too, can age. Heartbleed and other high-profile security problems are just one of the things to be concerned with. Software that is not maintained, that does not have a group or company standing behind it, is potentially dangerous. This support needn’t come from the original manufacturer — there are lots of historic cars still on the road, lovingly maintained by their owners — but it must exist.

A professional software engineer can and should assess the safety and reliability of software based on whether the system is well designed, well built, has been reviewed and tested, and is supported. Experience and judgement allow him or her to determine how much of each of these applies in each case.