Bridging the gaps in Software Engineering

After reading Steve’s analogy on software development vs. building bridges, I figured it would be easier to convey some of my own thoughts in a post vs. comments.


Being raised around engineering and architectural practices and now working in the software industry, there are some very clear differences in the disciplines. I to get picked on by my father who is a licensed Engineer which I have a lot of respect for. I think one of the most important differences between software engineers and Engineers is this question:


When was the last time a Software Engineer had to carry Errors and Omissions insurance?


I think this conveys the liability factor state certified Professional Engineers (P.E.) carry. This insurance covers the P.E. in the event a design fails resulting in a costly mistake or worse, the loss of life. This is the critical factor differentiating these two disciplines. To date, I do not recall a situation where we have allowed commercial software to make a decision about the well being of human without the ability of human intervention. So using the bridge analogy, is there someone always standing by to intervene if a bridge is in the process of collapsing and put a halt to it?


Well, someone might say, what about AED (Automated External Defibrillator) for example? Yes, that is true it is making decisions through software on the treatment to administer to the heart, but consider the ranges of input and the decision tree the device has to make. Also, humans are standing by to remove the device should it malfunction. Overall the programming of such a device would be considered trivial in comparison to a commercial software application. I may be wrong…


Enough on that point, I think we get it. I want to dig in a bit on the differences Steve points out, he is right, software itself has very little tolerance for mistakes, but in some cases it can still run with those mistakes. One wrong choice can bring down the entire application, but is that really the fault of the software development process? Consider the framework in which an application has to work within… the hardware platform, the operating system, etc. All of these elements are what leads to a single point of failure in software. If we could build systems smarter, then this would not be an issue in conjunction with reducing the complexity. Engineering is by its nature the application of known technology, materials, and knowledge to solve a problem. Very rarely is a total new material or technique developed. Researchers develop and define the expected behavior of a widget, but it’s the Engineer that determines how the widget can be applied everyday.


The most compelling aspect of this debate is the sheer number of decisions that must be made in software and design specifications. Sometimes software is asked to do more than it was designed to do. The random nature of data exposes design deficiencies in software. The analogy is attempting to place an aircraft carriers on a two lane bridge. First off the Engineer will tell you that I didn’t design the bridge for that load. The engineer designed the bridge with a given criteria in mind (max GVW of 10000 lb. x 5 vehicles). But that doesn’t prevent someone from driving a few tanks over it. The same is true in software. Yes, you can attach that 5gb file to your email message, but that doesn’t mean the software was designed to handle a file that large. As in bridge design, software is designed with certain criteria in mind, but the difference is software is expected to handle all possible criteria.


I am really at odds in regards to the comment regarding reinventing the wheel every time. If I recall correctly, only 30% of the code changes from one product revision to another. Even then the fundamental elements (algorithms, data types, etc.) are still reused in code, its how they are organized. The same with building a building. Engineers simply reorganize beams, rivets, etc. Software development bridges the gap between what is considered “pure research” and the application of the research (engineering). In many cases the architect or developer has to fill both shoes. But once a model of a widget is in place (research phase), engineering principals come into play in how we approach the refinement, testing, and documenting of the widget.


In summary, we should honor the roots of engineering and apply tried and true principals where and when it is applicable in our development and support processes.

Comments (11)
  1. Curt says:

    re: "When was the last time a Software Engineer had to carry Errors and Admissions insurance?"

    FYI, it’s "Errors and Omissions" insurance. And yes, it’s sometimes required in software consulting and contracting.

  2. Jeremyk says:

    Corrected Omissions… darn spell checker 🙂

  3. Daniel Auger says:

    Here is a great (albeit 10 years old) article on the state of "Software Engineering" versus other traditional types of engineering.

  4. Actually, it’s quite routine for software engineers to carry E&O insurance. Anyone who subcontracts to Microsoft is required to carry it, for example.

    But that minor nitpick shouldn’t be allowed to obscure the larger point that there’s a big difference between software engineering and the harder engineering fields in most cases.

  5. jeremyk says:

    So on the topic of "Errors and Omissions", my point was more so related to the ability to practice your profession. As a licensed P.E. by your state, you must carry E&O, either through your employer or personally. You can design a bridge for public use, but a PE must put their John Hancock on it, therefore accepting legal liability.

  6. vincem says:

    Cool article Daniel, thanks! It would be interesting to hear the authors opinion today.

  7. Daniel Auger says:

    Vince, I have been wondering the same thing. I think a lot of the things that have happened in the developer community over the past 10 years (Patterbs, Forums, Wiki, Blogs etc…) have filled in some of the gaps that were lacking for traditional reference material / knowledge transfer mechanisms.

  8. Peter Johnson says:

    Very cool article which every user should be made to read!! I think part of the problem is the majority of users who use software have no idea how it all works and can’t think virtually.
    <br>They seem to think you can do anything and it magically just happens and when it breaks it isn’t their fault. Most people wouldn’t take a tank across a bridge clearly marked with a 5ton limit but they would happily drop a 100mb attachment into Outlook and then scream at IT when it doesn’t work. Experienced this numerous times.
    <br>I think it’s the very nature of PC’s/software that causes this problem. I’m not sure that the principles that it operates on have been around long enough to sink into the collective conciousness of the world say the way driving a car has.
    <br>regards from South Africa
    <br>Peter Johnson

Comments are closed.

Skip to main content