“Software is a heap of trouble”. That’s the abridged version of this book.
You’ll find the full story in Scott Rosenberg‘s fantastic Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. One part of the tale follows the progress of the Open Source Applications Foundation project called Chandler; the other wends back through the history of computer science and software development. The story takes a good chunk of paper, around 350 pages + notes. None of it is terribly technical.
Chandler started with Mitch Kapor (known for Lotus 1-2-3, among other things) and the dream of the ultimate personal information organizer. E-mail, scheduling, calendars, notes, workgroup sharing & more, all in one cohesive and flexible system. In light of Rosenberg’s Law and its corollary (“Software is easy to make, except when you want it to do something new. And the only software that’s worth making is software that does something new.”), Chandler has proven a daunting task. It’s been over 4 years since Rosenberg started observing the OSAF team. As of this writing, Chandler is currently still only in version 0.7alpha4.
That creeping glacier of code raises the question: is it the team or just the nature of the job? Probably both. Rosenberg uses the hiccups and foibles of the OSAF team to explore some of the recurring issues of software development: the inherent mental difficulty of abstraction on a mass scale, the programmer’s tendency to “glance at existing code and declare authoritatively that they could do it themselves, faster, easier, and better,” the mythical man month, attempting progress without planning, the discouraging truth of Hofstadter’s Law, and the need to reinvent the wheel (and fire and stonecutting and agriculture, etc.). Luckily, Rosenberg doesn’t pose the Chandler team so much as the butt of the joke but the foil for the argument: software is hard.
One interesting thread in this book is the idea of programming as creative writing. Quoting Richard Gabriel:
We should train developers the way we train creative people like poets and artisits… What do people do when they’re being trained, for example, to get a master of fine arts in poetry? They study great works of poetry. Do we do that in our software engineering disciplines? No. You don’t look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don’t look at their design. You don’t study the lives of great software designers. So you don’t study the literature of the thing you’re trying to build.
The software industry doesn’t have a strong sense of history. Part of that lack is cultural—many just don’t care that much—and part of that is a necessary commercial evil whereby code is protected to protect profits. But I love that idea of the literature of software, the somewhat hidden heritage. This brings to mind the idea of artist qua collector and the idea of amassing influence. But for better or worse, there’s already way too much to learn just to keep up with the present. So the programmers plug on “borne back ceaselessly into the past,” if you’ll pardon the drama.