Is Software Development a Branch of Engineering?

I recently had a conversation with a friend regarding Software Development as an engineering discipline. Within the industry, there is a religious battle of sorts as to what Software Development is: a science, an engineering discipline, or neither. While the industry is in its infancy, it is clearly evolving towards something, and I’d venture to say that something is in fact an engineering discipline. 

The act of engineering, according to dictionary.com, is defined as “The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.” Similar definitions can be found on other online dictionaries. If approached from pure definition, it seems quite obvious that the discipline is one of engineering. True software developers (not script kiddies) plan, layout and design complex systems using mathematics and the scientific method. For example, if an individual is part of a team that is designing a complex financial system at a well structured organization, it is quite probable that they do everything from using rudimentary math all the way up to some advanced calculus topics to discover the best may to move data or route message calls. In addition, they may use mathematics to measure and analyze data that comes from load tests and use their analysis to optimize the system. It is quite certain that all software developers create hypothesis and then test them with the hopes of conclusively validating or invalidating them, ala scientific method. These different techniques would produce documentable results and allow software engineers to create plans of assembly and execution for an entire project. All of this does not vary much from stress and strain analysis that a civil engineer might execute, or their experimentation with different materials and mechanical configurations to support various structures. Although software engineering does not necessarily produce “tangible” results, the complexity involved can definitely be of the same scale. 

There is one problem, however, that prevents software developers from being unquestionably referred to as engineers, and that is how we approach our own profession. All too frequently, we discount the advantages of rigorous design and planning. We prefer the “Get it Done” methodology; that is, lines of code equals productivity and designing is a waste because there are “no results.” I’ve seen it too many times. This approach would be equivalent to a civil engineer (who is educated and has a degree) approaching the construction of a bridge by saying “Ok, I bought some steel, bolts and cables, lets start putting it together.” The engineer may definitely be able to build a bridge of some sort by the seat of his pants, but what is its load bearing capability? Has weather been accounted for? What were your design goals? This is the equivalent to what a software engineer must go through. We must realize that formulating answers to these questions is engineering, while the development is the construction. 

 Granted, there are some projects that do not necessarily need large amounts of design overhead (after all, how many civil engineers build earthquake proof dog sheds for their dog Spot), but that does not categorically deny the label of engineer. I do agree that there are many software developers that are not engineers because they have not pursued projects worthy of any real design, but that is a consequence and is situational. Even the most trivial projects can be engineered; it’s choosing whether or not one wants to. 

 On a final note in this long-winded discussion, I do want to address the external view. Many times in our industry, people we interact with (particularly our superiors) ignore design as part of the engineering process because they do not view what we do as engineering. It is our responsibility to prove to them otherwise. We need to build business cases for them as to why approaching a requirement change very late in the game (yes, I know all you agile folks have an answer to this) can in fact be very expensive and its not just “changing a couple of lines of code.” We all too often tell people, “No problem, we can make that change” without properly analyzing the ramifications. When was the last time a civil engineer didn’t mind someone that knew nothing about civil engineering coming and scribbling on their architectural and engineering diagrams and being told “ok, go ahead and make these changes to the foundation after its been built”? You’d be hard press to find one that says “Hey no problem, let me tear down half of what we did and redo it.” Granted, it does happen when a critical flaw is the cause of the request, but doesn’t if there was a missed requirement that the concrete should have been spiked with pink food coloring.