Bryan Cantrill has now fleshed out his critique of Dreaming in Code that I recently addressed. I want to thank him for returning to the topic and giving it serious consideration. I’m going to respond at length because I think, after clearing away a lot of smaller points, we’ve actually found an interesting point to dispute.
As far as I can tell, Cantrill is now saying that the problem with Dreaming is that it starts from the notion that “software is hard” and then explains why it’s hard by exploring what makes it unique — and he would have preferred a book that started from the notion that software is unique and then explored why its uniqueness makes it hard. At some point this becomes pretty abstruse, and I’ll leave it to those of you who want to compare what Cantrill says with what’s in the book to weigh our different perspectives.
I do want to correct his statement that I “picked a doomed project” from the start, as if that was my intention, in order to support a pessimistic view of software. At the time I began following Chandler, it had high hopes and a lot of enthusiastic support. I chose it because I cared about the problems it set out to solve, I thought the people involved were interesting, and I thought it had a reasonable chance of success. 20/20 hindsight leads Cantrill to dismiss Chandler as an ill-fated “garbage barge” from the start. But that’s hardly how it looked in 2002. It attracted people with considerable renown in the field, like Andy Hertzfeld and Lou Montulli, as well as other, equally smart and talented developers whose names are not as widely known. Nor, even at this late date, do I consider Chandler in any way to be definitively “doomed” — though certainly it has failed to live up to its initial dreams. There are too many examples of projects that took long slogs through dark years and then emerged to fill some vital need for anyone to smugly dismiss Chandler, even today.
Also, I need to say that my interest in the difficulty of software did not emerge as some ex post facto effort to justify the problems that OSAF and Chandler faced. In fact, as I thought I wrote pretty clearly, it emerged from my own experience in the field at Salon, where we had our own experience of a software disaster at the height of the dotcom boom.
Finally, in substantiating his criticism of what he calls my “tour de crank” of software thinkers, Cantrill still doesn’t make a lot of sense to me. In the two chapters near the end of the book that depart from Chandler to explore wider issues, I discuss the work and ideas of Edsger Dijsktra, Watts Humphrey, Frederick Brooks, Ward Cunningham, Kent Beck, Joel Spolsky, Jason Fried and Nick Carr (in Chapter 9), and Charles Simonyi, Alan Kay, Jaron Lanier, Richard Gabriel and Donald Knuth (in Chapter 10). (Marvin Minsky and Bill Joy, whom Cantrill mentions, are each cited only in passing.) Anyone might view some number of these figures skeptically — I do, too — but cranks, all?
Anyway, these are side issues. It’s later in Cantrill’s argument that we get to the heart of a real disagreement that’s worth digging into. Despite the evident pragmatism that’s on display in his Google talk, halfway through his post Cantrill reveals himself as a software idealist.
…software — unlike everything else that we build — can achieve a timeless and absolute perfection….software’s ability to achieve perfection is indeed striking, for it makes software more like math than like traditional engineering domains.
And once software has achieved this kind of perfection, he continues, it “sediments into the information infrastructure,” becoming a lower-level abstraction for the next generation to build on.
Ahh! Now we’re onto something substantial. Cantrill’s view that aspects of software can achieve this state of “perfection” is tantalizing but, to me, plain wrong. He makes a big point of insisting that he’s not talking simply about “software that’s very, very good” or “software that’s dependable” or even “software that’s nearly flawless”; he really means absolutely perfect. To me, this insistence — which is not at all incidental, it’s the core of his disagreement with me — is perplexing.
Certainly, the process by which some complex breakthrough becomes a new foundational abstraction layer in software is real and vital; it’s how the field advances. (Dreaming in Code, I think, pays ample attention to this process, and at least tries to make it accessible to everyday readers.) But are these advances matters of perfection? Can they be created and then left to run themselves “in perpetuity” (Cantrill’s phrase)?
On its own, an algorithm is indeed pure math, like Cantrill says. But working software instantiates algorithms in functional systems. And those systems are not static. (Nor are the hardware foundations they lie upon — and even though we’re addressing software, not hardware, it’s unrealistic to assume that you will never need to alter your software to account for hardware changes.) Things change all the time. This mutability of the environment is not incidental; it’s an unavoidable and essential aspect of any piece of software’s existence. (We sometimes jokingly refer to this as “software rot.“) Some of those changes break the software — if not over a matter of weeks or months, then over years and decades. It is then, I think, no longer accurate to call it “perfect” — unless you want to take the pedantic position that the software itself remains “perfect,” it’s the accursed world-around-the-software that’s broken!
This, of course, is a version of Joel Spolsky’s Law of Leaky Abstractions argument, which I present at length in Dreaming in Code: “perfect” abstractions that you can ignore are wonderful until something happens that makes it impossible to keep ignoring them. Such things happen with predictable regularity in the software world I know. I don’t know how you can discuss software as if this issue does not lie at its heart.
The strange thing about this disagreement is that, as far as I can tell, Cantrill is — like the engineers I know a lot better than I know him — a hands-on kind of guy. And DTrace, the project he’s known for, is by most accounts a highly useful tool for diagnosing the myriad imperfections of real-world software systems — for navigating those trips down the ladder of abstraction that software developers must keep making.
All of which leaves me scratching my head, wondering where the world is in which Cantrill has found software of “absolute perfection,” and which programs it is that have achieved such a pristine state, and how they — unlike all other programs in existence — escape the creep of software rot.
[tags]bryan cantrill, software, software development, dreaming in code[/tags]
There are no revisions for this post.