When people discuss software development, there is a certain tendency to overgeneralize. One should be careful to respect legitimate differences between some of the areas being compared.
Software as Engineering
The term “software engineering” has become fashionable in recent years, implying that software development is really just another specialty within the general area of engineering. Some people have taken this comparison further, suggesting that if software developers would just act more like other types of engineers, all this software stuff wouldn’t prove so difficult.
While there is certainly some validity to this comparison, it is also important to remember key differences between software development and other engineering disciplines.
Diversity of Purpose
While aeronautical engineering, for example, is about making things fly, the purposes to which software can be applied are amazingly diverse, and becoming more so all the time. So the things that work well for someone developing image processing software may be different from what works well for someone developing software to process banking transactions.
Rapidly Changing Environment
When one considers other engineering fields, there is generally some physical context for the discipline that changes infrequently, or not at all. A chemical engineer operates within the field of chemistry, for example, and the number of elements, and the basic chemical laws rarely if ever change. Other engineering fields are based on physics, or thermodynamics, or some other relatively unchanging body of knowledge about the physical world.
On the other hand, software “engineers” are operating within the constraints of the hardware available to them, and within the specified software environment — both of which are changing rapidly, and often in unpredictable ways.
So if a student studies chemical engineering, then he or she can be relatively confident that what they learn will be of use to them over their entire careers as chemical engineers.
On the other hand, software engineers often study languages, operating systems and hardware environments that may be entirely different five years after they have completed their studies.
Layers of Software Abstraction
Related issue are the complexity and mutability of the layers of software abstraction surrounding the problem domain in which the software developer is working.
Many developers today, for example, develop software that sits on top of an operating system, a database management system, application integration middleware, a web server, an application server and a set of language subroutine/class libraries, all of which are in more or less constant flux.
Scale
Watts Humphrey has made the point that a civil engineer, when considering the height of a structure, only has to worry about roughly a two order of magnitude difference between the smallest and the largest product he is likely to be called upon to design: that is, the tallest structure he is likely to work on is no more than roughly 100 times the size of the shortest structure.
On the other hand, software developers in college start out learning to write individual programs of roughly 1000 lines — but then, in the real world, are expected to work on projects developing more than a million lines of code: in other words, a difference of roughly three orders of magnitude.
Humphrey has gone on to suggest strongly that practices that work well at the lower end of this scale are not likely to scale well to the upper end.
Considering the factors above, one should be skeptical of the value of any list that claims to offer the “basic principles of software engineering”: the factors that cause success or failure will often vary widely based on one or more of these other variables.
