Rumors of Software Engineerings Death are Greatly Exaggerated (aka Software Engineering Ignorance, Part II)
- Posted on June 28, 2007 10:37:AM by Steve McConnell to 10x Software Development
- 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.