One of my commenters pointed me at an article by John Sonmez over at ElegantCode, Why Software Development Will Never be Engineering. The article makes one very shrewd, well-argued point, but then disappointingly fails to build on it. Read it and see if you spot the problem before I analyze.
I want to start by praising Mr. Sonmez for very logically and thoroughly arguing against a common kind of excuse-making. Often, when software engineers are asked why software engineering doesn’t have the reliability rates of, for example, bridge-building, the answer is: well, the discipline hasn’t had time to mature yet.
Sonmez observes that we humans have built a lot more software in the last 40 years than bridges in all of recorded history. His underlying point – which he makes very well by looking at how online play has terrifically accelerated the evolution of poker – is that in thinking about time to maturity in a discipline, cumulative hours of practice by humans matters more than the number of calendar years the techniques have been practiced. In terms of human practice time (Sonmez argues) software engineering has actually had at least as much time to mature as bridge-building.
I could quibble with this argument if I wanted to. The degree to which more people in a discipline can speed up its evolution is limited by the speed with which they can learn from each other in each round. There’s a diminishing-returns effect from adding more practitioners in parallel; it’s a lot like (and may actually be formally identical to) the Amdahl’s Law limit on speedup from processor parallelism.
But I think that really would be just a quibble, and that Sonmez’s underlying point about comparative evolutionary times is basically sound. And I wish he had stopped there, because it is just after this point that his reasoning goes all to hell and handwaves.
Before I get to dissecting that part, I’m going to note one startling detail that is orthogonal to Sonmez’s main arguments. At one point, as an example of change in the methods of software engineering, Sonmez says “Ten years ago waterfall was all the rage.” an assertion to which I can best sum up my reaction by quoting P.J. O’Rourke’s immortal words from Parliament of Whores, to wit: “What the fuck? I mean…what the fucking fuck?”
Here in the land of open source, waterfall development has been considered a form of doomed, brain-damaged idiocy as long as I can remember, let alone “as recently as ten years ago”. I suppose I could take Sonmez’s aside as a pleasing confirmation that my peers and I were ahead of the curve, but in fact my reaction is of gobsmacked shock at the thought that his peers were that far behind it. It gives me a suspicion that most of the software out there is actually far worse than I realized, a sort of nauseous sinking feeling.
But that’s not what I’m here to write about this fine evening. It’s probably not mostly Sonmez’s fault that he lives in a cultural surround where “ten years ago waterfall was all the rage”. It is his fault that, having constructed a lovely argument against one of the standard excuses for shoddy software engineering, he immediately begins failing even basic logic immediately thereafter.
Sonmez wants to argue that, since both disciplines have had comparable times to mature, the fact that they don’t have comparable error rates means software is fundamentally unlike bridge-building. But he has neglected to exclude the simplest possibility: that they are fundamentally alike, but the differing error rates are a consequence of differing complexity scales.
OK, so what do I mean when I say “they are fundamentally alike”? They are both disciplines in which the local behavior of components is usually simple and easily mentally modeled by a designer. The complexity, in both cases, generally comes from long-range couplings among parts that may interact with each other in unexpected ways. This is a hard distinction from, for example, biology – in which, basically, there are no simple components at any level.
I didn’t choose biology as a contrast at random. Sonmez appears to think that software engineers are more like surgeons. But that assertion just sort of hangs in the air; not only doesn’t Sonmez actually argue for it, he never even tells us what he thinks it means, beyond some poetic handwaving about software systems being “unruly beasts” and “keeping it alive”. Really, I could say “Software engineers are like blinching flugletharps” and convey exactly the same amount of information, which is to say none at all. What up, does Sonmez want us to wear scrubs and facemasks when we code? What’s the actual point of the metaphor, here?
The sad part is I don’t think Sonmez really has one. Yes, software has to be maintained. So do bridges, and taking a busily-traveled thoroughfare out of service for repairs has opportunity costs so high that it’s not done a lot more often than taking a large software system out of service for repair.
Now, it could be that the “fundamentally alike” case is wrong and that software is more fruitfully viewed as being like biology. The trouble is that Sonmez never gives us any reason to believe that. Everything after his “Software development is different” heading is pure handwaving. And, after the buildup, very disappointing.
I don’t think I know for sure whether or not software engineering is fundamentally different from bridge-building. But it’s a thesis I’m suspicious of precisely because it would in many ways be very comforting, almost an implicit excuse for our dreadful error rates. Sonmez isn’t doing us any favors by making a bad argument for the proposition, and he might not be helping matters even if it were a good one.
UPDATE: My wife the attorney acidly points out yet another way in which Sonmez’s argument is flawed and unhelpful. “If surgeons had the failure rate of software engineers,” she observes, “they’d all be in jail.”