Facts and Fallacies of Software Engineering
March 27, 2008
Via CodingHorror:
I’ve seen this book before when I taught software engineering, but never been interested in picking it up. However, just looking at the TOC (see the CodingHorror link above) pretty much tells you all you need to know about the current state of software engineering.
When I joined Florida Tech in 2002, I was asked to do an introductionary open lecture which to be a little controversial and "liven things up" (with the encouragement of some of the FIT CS staff), the title of my talk was "Why Software Engineering Isn’t ‘Engineering’". On the other hand, is it a craft, an art, or a science? I’ve tried to search for the PPT’s of that talk, but can’t find them at the moment - I’ll post them back here when/if I do get them from my backups. Found it 
The basic premise though was that engineering disciplines learn by their mistakes over time - it’s extremely rare that a major failure isn’t learnt from and never repeated again. Engineering is very predictable from how much effort/cost/material something is going to take to build, and how it will perform. I’m not sure we can say the same about software engineering - Les Hatton who was not only my research advisor but a great friend (and a fantastic guitar player!) has lots of data on how screwed up we are as an engineering discipline - I recommend looking through his slides and papers.
So, are we a craft? Not exactly. A craft is associated with usually someone who makes something (carpenter, plumber, violin maker, etc). There’s certainly a high level of skill in what these people do, but it’s usually an individual task with minimal "overhead" in what they do (plans, project management, etc) - it’s usually left to the craftsman for how to do something based on knowledge handed down through the ages. Software has some of these properties, but it’s not exactly a "fit"
How about art? I’ve seen some source code that might be considered "art" (both in good and bad ways!), but the main properties of art I think of are it’s aesthetic nature. There’s some element of art required in software (e.g. UI design), but it doesn’t feel like a good "fit" either.
Perhaps science then? The history of software is steeped in science so maybe that’s a better way of describing what we do. If we look at the definition of science then it’s a lot closer, but a science is the combined knowledge of a discipline, and not necessarily the application of that knowledge in building things (which producing software all about).
These are my thoughts, and a great coffee break discussion - YMMV.
Where does this leave us? The way that I think of it is that currently building software is a combination of all of the above - engineering, craft, art and science. I don’t think we are mature enough to be considered a "true" engineering discipline just yet, but we are working on it. Perhaps over time we’ll be able to make it there, but in the grand scheme of things we are still cavemen banging on (all-be-it expensive and featureful) rocks building not much more than the Stonehenge’s of our time. We’ve attempted to build equivalents of the Empire State Building or perhaps The Pyramids (in the form of aircraft control system, baggage automation handlers, healthcare data storage/retrieval, transportation systems, government systems, etc) with mixed successes, with the Web as perhaps the biggest and most successful thing we’ve done thus far. Until we can predict what we can build and know the effort/schedule it will take us with a reasonable degree of accuracy, I can’t with good conscious give us that "engineering" title just yet. But give us time - there’s obviously so much we can, and are, doing better.
Posted in Musings
