Graphsy Blog

This is something I’ve been meaning to write about a quite some time now.  It is one of the things that most irritates me about how Software Engineering (SE) is presented to people unfamiliar with the concepts.  It tends to be compared to other forms of engineering, especially architecture.  I have to admit that when first being taught SE, I fully bought into that whole analogy. But, when one moves beyond the basic concepts, it falls apart.  There are many problems with this comparison as well as many pitfalls one may fall into when making it.

Engineering has been around for many thousands of years.  Ancient Egyptians had engineering to construct the pyramids, there was a process and design in place to do so.  Engineering is naturally based in the real world.  We can think of engineers as applied scientists, they perform very similar duties, except their goal is not to answer questions about our world, but to create something that will make our lives easier.

The advantages of dealing with the physical world is that many constraints are placed on what it is that can be created.  How objects interact with one another, how different materials react to stress, and how these pieces can be combined to make a greater whole can be modeled and experimented with on different scales.  Engineers can create experiments based in the real world and try them to see what would happen.  Because we have been doing engineering for so long, there are well established processes which can be used and applied to solve problems. There are also well established metrics in different engineering domains which tell you if something is better than something else.

However, the issue of dealing with the physical adds several problems.  Engineers need to be concerned about wear and tear of whatever it is they build.  Nothing really survives forever, just maybe for a long time.  This limits how much and how fast work can be done.  And, because actually constructing the engineered product can be very expensive, engineering tends to have a very long design process.  The necessities of cost facilitate the fact that one has to be careful, thus the adage “measure twice, cut once.”

The final fact of engineering we need to consider is that most engineered products are designed as standalone.  While they can plug into and work together with other products, they are not intended to evolve over time.  When building a house one does not typically consider what significant changes one may wish to do to it later.  That’s why creating additions can be a very expensive proposition.

When compared to engineering, SE takes all of these constraints and flips them around.  First, software engineering is a very young profession, only a few decades old. Second, there is little cost is physically creating software, the majority of the cost falls to paying development teams.  Third, there are no good metrics that tell you if one piece of software is better than another.  We can’t make guarantees that our software will not crash, only increase our confidence in it.  Fourth, because software engineers are not concerned with the physical world, the complexities of the product being developed skyrocket.  Just think about the phone network.  The kinds of data and switching that can be done with software is far above what was being done with the original, physical, phone switches.  And finally there is the idea of software evolution.

Unlike other engineering products, few large applications are build from scratch, most borrow and reuse code from their ancestors.  This is more commonly referred to as the legacy problem.  There are critical legacy systems out there that no one understands.  In fact there are many reverse engineering projects whose sole purpose is to figure out how those systems do whatever it is they do.  Because a software problem can be solved a multitude of ways, none of which are necessarily obvious, it has become more and more difficult to just maintain information about what the system does and how it does it.  This is probably the biggest problem facing the SE community in the coming years.

The only real similarity between engineering and software engineering is that the practitioners of both end up creating something in the end.  After that the similarities end.  Trying to pigeonhole software engineering into other forms of engineering does it no service.  Because physical engineering has long design times, we got stuck with the waterfall model of development, meaning long design time and then supposedly short development time.  While good on paper, it fails in practice because design decisions are made before the software is really understood and the final product tends not to match the design at all.

Creating software needs to be approached as an entirely different problem.  There is some evidence in ideas such as Extreme Programming and SCRUM that we are slowly beginning to change our views on the issue, however more still needs to be done.

This entry was posted on Friday, September 26th, 2008 at 1:03 pm and is filed under opinion, software engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.