Software Engineering Ignorance

  1. Posted on June 23, 2007 10:15:AM by Steve McConnell to 10x Software Development
  2. Management, software engineering

The February 2007 issue of IEEE Computer contained a column titled "Software Development: What Is the Problem?" (pp. 112, 110-111). The column author asserts,

"Writing and maintaining software are not engineering activities. So it's not clear why we call software development software engineering."

The author then brushes aside any further discussion of software development as engineering and proceeds to base an extended argument on the premise that software development is not engineering. I agree with the author that the specific act of giving instructions to the computer doesn't much resemble engineering. However,the fact that one software development activity out of many doesn't resemble engineering does not imply that software development as a whole doesn't resemble engineering. Numerous software development activities have clear counterparts in other engineering disciplines, including:

  • Problem definition
  • Creation of models to verify the engineer's understanding of the problem
  • Feasibility studies to verify viability of design candidates
  • Design as a central activity
  • Creation of detailed plans for building the product
  • Inspections throughout the product-creation effort
  • Verification that the as-built product matches the product plans
  • Ongoing interplay between the abstract knowledge used by engineers and the practical knowledge gained during construction
  • etc.  

This list could be much longer, but these items are sufficient to illustrate the point that, even though giving instructions to the computer doesn't have a clear counterpart in other engineering disciplines, many software development activities do have clear counterparts. 

Taking a step back from the specific argument, I find it distressing that writers in 2007 are still propagating the myth that software development cannot be treated as engineering. We can certainly debate the value of treating software development as engineering, or software engineering's appropriate areas of applicability; but any debate about whether software development can be treated as engineering ignores the fact that it is being treated as engineering, and deeply so:

  • The Computer Society adopted a Code of Ethics for Software Engineers almost 10 years ago.
  • The IEEE Computer Society approved the Software Engineering Body of Knowledge 2.0 in 2004, which was adopted as an ISO/IEC Technical Reference 19759:2005.
  • Curriculum guidelines and accreditation standards have been established for undergraduate software engineering programs.
  • In the United States the official engineering accreditation board, ABET, has accredited 13 undergraduate software engineering programs since 2003, and in Canada 9 such programs have been accredited (by CEAB).
  • Numerous provinces in Canada license professional software engineers, and professional engineers are chartered in software in England. 

It's appropriate and useful to debate in what circumstances should software development be treated as engineering, or what kinds of software development work better when not treated as engineering, or what portion of software development should be treated as engineering, or how engineers in software should be trained, or what proportion of software developers really need to be software engineers -- but arguing whether it's possible to approach software as an engineering discipline is years out of date.

What do you make of the fact that we can have a software engineering body of knowledge that has been adopted as an international standard (ISO/IEC TR 19759:2005), we have bachelor's degree programs in software engineering, we have accreditation standards for those programs, numerous programs have actually been accredited--yet people are still arguing whether software can be treat as engineering? Is the issue simple ignorance, or is it something deeper?

gilz said:

June 24, 2007 1:09:AM

Maybe it gives us (the software builders) an excuse for failure? If it's an "art" then there's an acceptable failure percentage, unlike with "real" science.

AndyBurns said:

June 25, 2007 2:47:AM

That sad thing, I think, is that although software development should be like traditional engineering, usually it isn't. Failure is acceptable, even expected - "To err is human, but to really f%^k up takes a computer". Time and again I see projects with inadequate specification, unclear goals, unrealistic budget, etc. and I think 'This isn't how you'd build an aeroplane'.

I guess it's a question of consequences. If a server falls over, you restart it. If a plane falls from the sky, it's a big deal. So planes are expensive, and don't crash very often, and servers aren't, and do.

I read Richard Feynman's "Personal observations on the reliability of the shuttle" and the thing that really struck me was how he actually praised the quality of the Shuttle's software. And it seems to me that they achieved this by treating the software exactly like an engineering discipline, and accepting that this adds time, effort and cost. Sadly, most companies will not accept this. Sure, they might say they want 99.99% reliability, but you try getting them to pay for it. The difference is, NASA can't afford failure.

Thus, for most customers, except maybe parts of the government and military, engineering rigor and process goes out the window in favour of 'hacking' together a solution.

Kevin said:

June 25, 2007 2:00:PM

"Writing and maintaining software are not engineering activities. So it's not clear why we call software development software engineering."

Let's paraphrase a bit.

Welding metal and bolting beams are not engineering activities, so it's not clear why we call construction civll engineering.

Well, duh, it's not. But just as above, deciding how good the bond has to be and what kind of I-beam to use (even though you can weld and bolt without being on an engineering project) is engineering, so are the processes mentioned above.

So there.

susan said:

June 25, 2007 10:55:PM

This is discouraging, but not surprising. I often find even software 'engineers' that don't treat their jobs as a serious discipline. There are probably more software hacks than software engineers out there. It goes without saying, to those of us who know, that software development benefits greatly from the best practices of other engineering disciplines. But too many of our brethren ignore these best practices. And that is part of the perception problem.

finnsson said:

June 27, 2007 1:47:AM

Eric Wise has counterpoints on

Benjamin Carlyle said:

August 4, 2007 2:43:AM

I think that Software Engineering is a real engineering discipline, however it is an immature discipline. We are only just beginning to name the essential inventions in software and build standard interfaces to them.

Our experience in software so far has been Computer Science. We have been experimenting with ways to interact with and program a machine. We have been trying to understand the effect of algorithms and figure out what the natural level of complexity is in our work. A mature engineering discipline requires more than this.

I think the defining difference between a mature engineering profession and the current state of our software engineering is a lack of components. Drafting a bridge or a printed circuit board is a design process. However, the design is based on known parts. We know the stresses a particular I-Beam can take. We can order 1000 of them and build the properties of our bridge apon them. We can order specific chips and assemble them into a product on our circuit board. These boards can themselves be manufactured en masse. Their properties can be determined and bigger systems can be built around them.

Software projects still seem to involve much more invention of components than composition of components. I suspect that many more domain-specific components need to be available for assembly alongside more general components. General components such as "database" or "web server" can only take us so far. We also need more "power consumption predictors", "automatic train routers", "voip telephony endpoints", etc. We are only just starting to name these things. We are only beginning to build the social, legal, and technical standards  that would allow us to reliably and predictably engineer systems from them.


Sally, project manager said:

August 29, 2007 4:28:AM

I share you opinion, but wanna add, that sometimes we loose the real meaning of the word and give it another one.

Post a Comment:


Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laude, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve