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

• Anonymous
  March 02, 2005
  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.
  

• Anonymous
  March 02, 2005
  Corrected Omissions... darn spell checker :)

• Anonymous
  March 02, 2005
  Here is a great (albeit 10 years old) article on the state of "Software Engineering" versus other traditional types of engineering.
  
  http://www.sce.carleton.ca/faculty/ajila/4106-5006/Prospect%20Eng%20Soft.pdf

• Anonymous
  March 02, 2005
  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.

• Anonymous
  March 02, 2005
  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.

• Anonymous
  March 02, 2005
  Cool article Daniel, thanks! It would be interesting to hear the authors opinion today.

• Anonymous
  March 03, 2005
  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.

• Anonymous
  March 31, 2005
  The comment has been removed

• Anonymous
  March 18, 2008
  PingBack from http://desktopcomputerreviewsblog.info/jeremyks-msft-weblog-bridging-the-gaps-in-software-engineering/

• Anonymous
  June 16, 2009
  PingBack from http://lowcostcarinsurances.info/story.php?id=2235

• Anonymous
  June 17, 2009
  PingBack from http://patioumbrellasource.info/story.php?id=1358