Rumors of Software Engineerings Death are Greatly Exaggerated (aka Software Engineering Ignorance, Part II)

  1. Posted on June 28, 2007 10:37:AM by Steve McConnell to 10x Software Development
  2. Methods & Processes, Management, software engineering

A reader of my previous blog post on Software Engineering Ignorance pointed me to Eric Wise's blog post Rejecting Software Engineering. Eric seems like a bright guy, and he's a persuasive writer, but his post is another example of what I was referring to in my earlier post -- that is, people who are uninformed about software engineering spreading misinformation about it.

One of Eric's arguments that is representative of other published arguments is that "software isn't like real engineering." But the "facts" he presents about real engineering are way off base. For example, he asserts early in his post that real engineering has "near perfect information on durability, composition, balance, etc.," but that claim is idealized and not correct. When John Roebling designed the Brooklyn Bridge, for example, the properties of steel cables weren't well understood, and so he used a safety factor of FOUR in designing the cable supports for the bridge. Obviously that is not even close to "near perfect information." Indeed, one of the hallmarks of engineering as opposed to science is that engineers will work with materials whose properties are not entirely understood, and they'll factor in safety margins until the science comes along later and allows more precision in the engineer's use of those materials.

Eric's post goes on to use poor estimation in software as a point against treating software as engineering: "Look at the estimation problems we have in software." Again, this assumes an idealized and incorrect view of other engineering disciplines. Can you say "Big Dig?" The largest "real engineering" project in recent memory, the Big Dig was originally estimated to cost $2.6 billion. The final cost was about $15 billion. [Thanks to an alert reader for pointing out an error in my numbers, now corrected.] In Seattle (where I live), the construction cost of the Seattle Mariner's baseball stadium ended up being nearly double the original estimates. There have been many, many cases like this, which I discuss in my book, Software Estimation: Demystifying the Black Art. Estimation error in software is not any better or worse than it is in other branches of engineering -- the central issue is that estimating large, one-of-a-kind artifacts is always going to be subject to a high degree of error. Estimating the 40th similar house you build in a housing development is easy, but so is estimating the 40th similar customized version of a software product you deploy.

Eric's post cites the fact that there are 10:1 differences in programmer productivity as an argument against treating software as engineering. Oddly, Eric cites drywall installers in support of this point, I guess to say that drywall installers are associated with traditional engineering. Here again, Eric needs to check his facts. Has he ever worked with drywall installers? I can tell you from personal experience that there is definitely a 10x difference between drywall installers, especially in terms of quality. Some guys install drywall in a way that makes it nearly impossible to texture well. Other guys get it right the first time, and texturing it is really easy.

The fact is that 10:1 differences in productivity and quality aren't unique to software, and so that fact doesn't differentiate software from engineering or from anything else. There was an interesting study conducted in the 1970s that found that the 80/20 rule applies in virtually every discipline: 20% of the programmers write 80% of the code, 20% of the police detectives make 80% of the arrests, 20% of the NFL quarterbacks make 80% of the touchdown passes, 20% of writers write 80% of the best selling novels, etc. Eric's observation that there are significant differences in productivity is valid, but it doesn't have any bearing on whether software is engineering.

Eric invokes the work of David Parnas as an argument against treating software as engineering, and says Parnas's work in information hiding undermines the openness that is needed for real engineering. I honestly could not follow the logic of his argument on this point. Moreover, Parnas has been one of the earliest and most prominent proponents of treating software as engineering. Indeed, Parnas founded Canada's first undergraduate program in software engineering at McMaster University.

Software engineering already has been defined as engineering, we have an international reference standard for that definition, the field's two largest professional bodies have jointly adopted a professional code of conduct for software engineers, we have accreditation standards for university programs in software engineering, we have university numerous programs that have already been accredited, and several countries are licensing professional engineers in software.

Eric's conclusion that "I don't think software development will ever be able to be defined as engineering in the traditional sense" is a good example of the kind of uninformed opinion that I wrote about in my previous post on this topic. But I don't mean to pick on Eric -- no one can be expected to be well informed about everything. Eric's post simply highlights the fact that rumors of software engineering's death have been greatly exaggerated, and we need to do a better job of spreading the word that, in reality, software engineering is alive and well.

martincron said:

June 28, 2007 11:54:AM

It seems that if you look at Engineering as just another metaphor for software, you can evaluate the the "is Software Engineering really Engineering" question the same way you evaluate other metaphors for software.

Lean Software proponents talk about Toyota. A lot. But building software is not very much like building a car. It's more like designing a car. Even then, the metaphor falls apart, as Lean advocates early and incremental delivery, while nobody would want incremental delivery of their new Camry.

So, as with any metaphor, you can't swallow the the thing whole. It's dangerous to say that "we have to build software this way because that's how engineers build bridges" It's also not a good idea to totally ignore how engineers have traditionally worked, because many (not all) concepts and practices are applicable.

The distinctions should be pretty clear, as they are not based on fuzzy academic concepts such as "what does engineering mean?" but the around the differences between making something physical and making something wholly intellectual.

For example, a lot of "physical world" engineering is about being able to make essentially the same thing or similar things over and over to the same standards.  If you find yourself doing too much of that in software, you've probably missed an important abstraction.

cdsmith said:

June 28, 2007 10:08:PM

I suspect a lot of the complaint about whether software engineering is really engineering is misleading.  People are disagreeing as much about the meaning of engineering as about software development.

In his famous contribution on software engineering (in the 1998 Annals of Software Engineering), I think most people agree that Parnas went too far.  He proposed a software engineering curriculum with required courses in heat transfer and thermodynamics, material science, mechanics, electromagnetism, and on and on.  How many people would defend this idea today?

Clearly there are differences and similarities between the work of bridge designers and software developers.  Whether the similarities or the differences are, by and large, the parts called "engineering" is not a particular interesting debate.

Chris Norton said:

June 28, 2007 11:36:PM

I do believe misinformation about "real" engineering is a problem is some of the more contemporary engineering disciplines but especially in software engineering. I'm not sure why this is but it's probably a combination of the relatively young age of software engineering and the intangible nature of our building materials.

Really, if you just take the time to read some of the literature on structural engineering ("real engineering"), especially the works of someone like Henry Petroski, you'd understand that all engineering disciplines have largely the same issues (complexity, uncertainty, environmental factors, legals, etc), need the same basic skills (analysis, problem solving, management, etc) and have similar links to things like art, social science and so forth.

One thing that's important to keep in mind is that it's true that programming != software engineering. Many people might get confused because the work that they do, or that they see done, really wouldn't be described as engineering so they assume this goes for ALL software development.

patrickriva said:

June 29, 2007 1:22:AM

I sawEric Wise's post and I wanted myself to write an entry in my blog about it. I agree with Steve on all the point he made and I would add a 'justification' for the delays in software development projects.

Let's take the bridge analogy and suppose we planned to build a bridge with dual carriage, dual track for car & trucks and we're halfway in the construction. What would happen if the customer asks the engineers to make the bridge a dual carriage, four track bridge? or to add a train track? Probably the engineers start laughing or they came up with proposal that imply huge delays and huge extra costs. The original estimates are broken.

Now, how common is it in software project to have the customer coming to you during the development and say 'the system doesn't do this and that, and we want it to do it'? Well, that for me is an extra track in the bridge that breaks the estimate, to the customer, of course, all software changes are 'soft' changes and he expects them for free or at a minimal cost.

So probably the problem is in the name of what we are doing SOFTware. Now, since hardware has already been used we should come up with something else... let's do complexware?  :)

MrHatken said:

June 30, 2007 3:58:AM

I think the question is not if software development is engineering but why don't a lot of developers take an engineering approach to software development?

I think there are a number of reasons.

Firstly, I think this comes back to the comment AndyBurns made in the last blog entry - in a lot of cases developers can get by and produce something that ostensibly works without doing engineering.

Secondly, if left alone, software will generally continue working as it does when first delivered.  As long as a developer is persistent enough to build the stack of cards, it will stay standing.  

Thirdly, again generally speaking, clients are either unaware of this or happy to live with the risk (given the reduced cost), and even the the fact that maintenance costs may end up being much higher.

Such risks and eventual decay are not acceptable when building bridges, aeroplanes, etc.  Of course, where there is high risk associated with software, clients are generally prepared to pay more and developers do more.

Finally, because there is a lack of understanding of software (and technology in general) amongst clients, it is difficult for them to distinguish quality developers and to estimate a reasonable cost.

A 17 year old claiming they could build a bridge across the East River for $10K wouldn't get very far.  But with software its a lot harder to distinguish quality developers (CMM level) and what's a reasonable cost.  

All that said, I believe we can build software faster, cheaper and better using an engineering approach, but the discipline is young and we have a lot to learn (as a discipline and individually).

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 Laud, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve