Dreaming in Code
The only reason I like to travel is being able to read, especially on long flights. So, Charleston, SC – San Jose, CA trip to SD West was a good opportunity to read “Dreaming in Code”. Good book. About OSAF‘s development of a PIM named Chandler. Unfortunately, not comparable with The Soul of a New Machine to which it is often compared. Why not? For the most obvious reason – The Soul of a New Machine is a story of hard work, strong leadership, good management and success. Dreaming in Code is, with all due respect to Mr. Kapor, a story of a management disaster that no amount of hard work could salvage. The Soul… is a “how-to”. Dreaming… is “how-not-to”. At one point, Kapor brings Al Gore in the conference room. Al Gore says: “I’m Al Gore. I used to be the next president of the United States”. And goes on, saying: “Keep up the great work! You guys are changing the world.” And then leaves the room. Go figure.
Other than the above annoyance, for which I see no importance whatsoever that merits a mention in a book, I was pretty much able to identify and agree with Rosenberg’s positions. So, let’s get to the book now. I have made notes of interesting quotes (author’s and otherwise) that appear in the book:
“choice of programming language often comes down to the arbitrary or the ineffable – a matter of taste or habit or gut sense”
Very much true. You can’t beat the gut sense. Some languages (and not just languages) simply “feel right”.
Michael Toy: “… the fools were paying me money to do what I would have done for free if only they had known.”
What true programmer can not identify with that? I mean, heck, we are all like that. Don’t tell anyone, but I’d do it for peanuts 😉
Citing Peter Drucker: “Management is about human beings. Its task is to make people capable of joint performance to make their strength effective and their weaknesses irrelevant.”
Very true. What a contrast with a lack of leadership demonstrated in the Chandler project.
“There is no reliable relationship between the volume of code produced and the state of completion of a program, its quality, or its ultimate value to a user.”
“It takes a pretty alert and knowledgable manager to tell what software developers are doing.”
Absolutely true.
Citing Brooks: Tower of babel failed because its builders “were unable to talk with each other; hence they could not coordinate. When coordination failed, work ground to a halt.”
Good old Brooks, still accurate today as he ever was. Or is it actually the Bible that’s accurate?
MIT graffiti citation: “I would rather write programs to help me write programs then write programs”
POCO anyone ? 😉
Abe Lincoln citation: “Give me six hours to chop down the tree and I will spend the first four sharpening the ax.”
Fits well with the above graffiti. AKA 80-20 rule: Do 80% of the work in last 20% of time. It’ll be done on time if you’re lucky. Otherwise, the release will be – well, late. Welcome to the world of software development.
“Reaching back to ancient Rome, Kapor proposed applying to software the architecture theorist Vitruvius’ principles of good design:
– firmness – sound structure, no bugs
– commodity – a program should be suitable for the purposes for which it was intended
– delight – the experience of using the program should be a pleasurable one”
All valid points, very much along the Christopher Alexander’s patterns (btw, that’s what I’m up to now – to finally read Alexander’s opus magnum). In theory. Implementation has obviously failed dismally. Essentially, the above are the elements of alive (I use the term “alive” here, Alexander calls it “quality without a name”) patterns, all applicable on multiple levels:
– user interface for the end user
– library interface for the application programmer
– programming language “interface” for the library programmer
– machine “interface” for the compiler writer, etc. ad infinitum
The main moral of this painful story comes in quotes from the interview Linus Torvalds gave to Linux Times in 2004:
“Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll overdesign … If it doesn’t solve some fairly immediate need, it is almost certainly overdesigned … Don’t expect to get anywhere in any kind of short time frame …”
Or as Beverly Sills said: “There are no shortcuts to any place worth going”.
“It turned out that improving how you organize code was a cakewalk compared with improving how you organize people and their work.”
This really hits the essence of the project failure – the management issue. People are difficult. Leadership is important.
In the end, what to say about the book and the project it describes? It is a good book, bringing many important software development issues to the surface in the context of a real project. Essentially, it is a description of software development anti-pattern. Too many dilemmas and labor over them, to little decisions at critical times, to many direction changes, too many people came and left. It is disappointing to finish a book about a project with the project unfinished, but even if you didn’t know it before, somewhere in the middle of the book it becomes clear that this project will never be finished. And even if it is, it will be so late that it’s not likely to have any relevance. But, as it usually is, it may just so happen that something totally unexpected comes out of it.
BTW, have you ever dreamed in code? I do it all the time 😉
std::cout << “YAWN!” << std::endl;
std::cout << “ZZZZZZ”;