I came across some fresh speculation about the enduring mystery of why so much of the software we build is so bad. This discourse at Better Living Through Software entitled Software that Doesn't Stink links the discussions instigators before adding a good size chunk of supporting commentary.
The notion that programmers who been around for a while develop a tolerace for a certain degree of "code clutter" rang true for me. What's more, I don't see this as only as a possible abdication of concern for the system's design integrity, but possibly also as a necessary means of holding conflicting, centrifugal forces at bay. Big Ball Of Mud speculates that different programmers differ in their capacity and willingness to cope with such clutter. The Selfish Class raised the possibility that inscrutable code may, ironically, resist change better than more readable code.
The observation that there is an appaling amount of waste in many organizations rings true, up to a point. There are a lot of forces at play here, and no single factor will be able to account for it all.
It seems like many organizations assume they need much larger teams, with their attendant support, than they really do. They employ an "infantry model" to staff their projects, when a "commando team" model might be sufficient, as well as more effective...
Joshua speculates that the software industry attracts a certain sort of idealist; persons enamored with the seemingly unliited maleability of this stuff we call software, and captivated by the sheer power that command of such stuff brings with it. One of this most exhilarating thing about programming is that, with enough effort, one can master the intricacies of what is "under the hood" all the way down to the silicon.
Or, one could. During the the '70s and, again, with the advent of the microprocessor, a single individual could master vast swaths of all the code that ran on their machines. These John Henry programmers could single-handledly design, code, and test quite substantial applications. Making all their design decisions inside their own heads kept communication overhead to an absolute minimum.
Are the most accomplished soloists less adept at ensemble work? Are commando coders hamstrung when co-ordinated co-operation is called far? Did those scurillous calumnies about the purportedly poor social skills of the cream of our indigenous hacker culture have any truth to them what-so-ever?
In any case, how surprising might it be were people who were trainted to be Crackerjack solo coders are surprised that collaborative work moves, by comparison, at a stately, even glacial pace?
Joshua observes that coders seem to do what they are good at doing; what they know how to do; regardless, it would seem, of whether doting on these dimensions for improvement is really a good use of their time. You get hand-coded inner loops that exhibit near theoretical peak performance, along with business logic that, at times, seems oblivious to task at hand...
He offer two additional pathologies, competition among programmers to excel at say, optimization, at the expense of master the intricacies of the domain. This sounds plausible, craftsmen of every stripe engage in this sort of one-upsmanship. I'm reminded of a story about the plasterers who stuccoed my house (which I will try to find).
The other is designing for extensibility. This too has, at times, had a certain cache among hackers. Therein lies a tale...
One of my sources for material for this weblog will be a collection of research diaries I've been keeping on paper since the mid-'80s, and electronically since 1993. As a result, entries might appear from time that will predate not only MovableType, but even the Web itself. This weblog may, in a sense, seem "unstuck in time" like Vonnegut's protagonist, Billy Pilgrim, in Slaughterhouse Five.
