Dreaming in Code (S. Rosenberg)

Confession: I had the hardest time understanding relativity. Not such a big deal for the average Joe, but quite a handicap for a physicist like me. I could certainly apply the equations, that was straightforward enough. The inner logic of it all, though, escaped me.

Take the twin paradox, for instance: one of two twins leaves for an extended trip to another star, and the other one is left behind. When the traveling brother sees the other one on screen, the latter’s speech is slowed down, a relativistic effect. I saw that on Ustinov explaining relativity. The Earth-stuck twin, in turn, sees the fast brother talking at twice the speed. Says Asimov.

I never got that, it didn’t make any sense to me: the whole point of relativity, it seemed, was that you couldn’t tell which one was traveling and which one was unmoved. And while I could easily debunk the notion that one’s time would speed up as the other’s slowed down (they both slow down), it still didn’t make sense that one twin would have aged less than the other.

Then, on one dreary afternoon, I stopped in the library and set my eyes on the old Annalen der Physik. To a physicist, the year Einstein came out with special relativity is etched in your mind: 1905 the world of physics changed. I stopped at the volume labeled 1905, looked for the article, found it, read it, and finally got it. (The age difference is due to acceleration, not speed. You don’t age less because you are fast (which you couldn’t tell, anyway) but because you had to accelerate back into the frame of reference of your twin.)

So, I fault Ustinov (more concretely, his writers) with confusing me on relativity. What does that have to do with a review of the book at hand?

Dreaming in Code is an account of Mitch Kapor’s attempt to start an open source project for a PIM. The project was a complete catastrophe on all accounts: it ran through tons of money without ever generating any real open interest; it was burdened by really dumb policy and architecture decisions; it was led by a series of people who really needed a lot more open source experience; it was run as an enterprise project. No surprise it failed in the open source marketplace: you really just needed someone on board that understood open source and you would have had a chance to succeed.

Being in the business, though, this part of the story reads like so much “been there, seen people do that.” Mitch Kapor came from Lotus, shrinkwrap for pay software, and he had no instincts for open development. It all reminded me of Yahoo!’s attempt to create group that was to sell software to Fortune 100 enterprises – all led by people either from Yahoo! or chosen by Yahoo! people. We ended up with a product that missed all enterprise requirements, with a salesforce that didn’t know how to sell to enterprises.

Finally getting to the part about “confusing,” this book falls in line with the plethora of attempts by non-technical people to explain technical content. There are two main criticism I have to raise of such attempts:

1. They end up being terribly inaccurate, forcing comparisons between things that are unrelated, and explaining content in ways that are subtly, but irritably wrong. Unfortunately, as anyone with technical expertise in any field will tell you, those errors are not irrelevant (as many authors claim) but distort the reader’s understanding just enough to cause terminal confusion – as was the case with relativity and me.
2. The authors tend to pursue a strategy of covering their technical half-ignorance with a patronizing and pontificating tone that leaves no room for amusement. The technical explanations in the book might have been interesting if tongue-in-cheek, but as the axioms of reasoning of the book, they are just plain out of place.

Interestingly, the author explains he didn’t write this book just for developers, but for a wider audience. That’s good, because I doubt developers will accept his treatment of software topics as even remotely passing grade. The general reader, though, may find that the story doesn’t make a lot of sense without an explanation of development processes and programming logic.

It’s a real shame that Mr. Rosenberg didn’t talk with a good software architect before publishing his book. Factual inaccuracies are not the big deal; the ever slightly off-key perspective is. Sitting from the outside, Chandler was doomed by its wrong focus, not by the number of bugs. Lack of functionality killed it, not wrong management techniques.