Dreaming In Code

In a spontaneous fit of self-referentiality, I’m now going to mention a book, in this blog, that mentions this blog, in the book.  🙂

Scott Rosenberg’s new book Dreaming In Code, which is mostly about the Chandler project I work on for OSAF, mentions a couple of my blog posts here about the project, mainly to describe them as, uh, “indelicate”.

One of the posts, Python is Not Java, remains highly popular to this day.  But Rosenberg bizarrely interprets this post as “publicly exposing the OSAF team’s goofs”, despite the fact that the code was available for anybody on the internet to download and see for themselves!

Plenty of them did – and some Pythonistas critiqued it far more harshly than I did.  I was the only person who attempted to write something educational about what should be done instead, rather than writing the project off as a joke.  That post will continue to be a useful article for people migrating from Java to Python, long after its relationship to Chandler is forgotten.

(Not that most people know the relationship in the first place – you’d have to have examined the Chandler code base yourself, or read somewhere else that the post was related, despite Rosenberg’s claim that it was “pretty clear who [I] was talking about”.  Clear to whom?)

Strangely, the two mentions of my blog in the book don’t seem to go anywhere; they’re almost a sidetrack, as though there was going to be a subplot about the work I was doing, that faded out because it got too technical or something.  (My first big OSAF project was ripping out all the XML schema/UI specification and replacing it with a faster, more maintainable Python API – not exactly mainstream bestseller stuff.)

Honestly, if I were editing the book, I’d probably have cut my three pages out entirely, because it’s a tangent of little interest that goes nowhere.  (Heck, for all I know, an editor might have actually cut those three pages out of the final version, because I’m just reading a preview version that’s been circulating amongst OSAF staff.)  It seems that the only purpose was to show how great OSAF is because they were able to look past my “indelicate” nature and still “adapt good ideas” from my work.

But that bizarre conclusion springs from Rosenberg’s misunderstanding of the purpose of Spike.  The problem I was experiencing at OSAF initially was that nobody was taking my refactoring proposals seriously, because they couldn’t conceive of what the end result would look like.  It was just too foreign a concept at that point, and therefore the perceived risk of my initial proposals was too high.  Essentially, people were arguing that what I proposed was impossible, because they didn’t see how it could be done.

So the idea of Spike was to provide a concrete example to point to of “see, this is how something written Pythonically could work”, and to demonstrate that something of that sort could in fact be implemented both quickly and robustly, while providing an easy-to-use and understand API.

In other words, the point was never to be an actual replacement for Chandler’s architecture, but rather to provide a prototype of what it could be like.  So, the whole point of the exercise was to “adapt good ideas” from it!  That’s also why it was done as quickly as possible and in as minimalist a style as possible – its purpose was to sell ideas to management and developers, not to deliver a replacement architecture.

Spike’s purpose, in short, was to raise OSAF expectations about what could be done in Python (mirroring the theme of the blog posts Rosenberg cites) and to make a shift in thinking from ruling things out as “not possible”, to asking, “what should we do, and how can we do it?”

In short, Rosenberg’s narrative creates a dramatic tension that didn’t actually exist in the situation, while ignoring the ones that actually did exist in the situation.  Which makes me wonder how much more of the book (which is mostly about stuff that happened “before my time” at OSAF) actually reflects what was really going on in the rest of the project.

Oh well.  One person at OSAF explained it to me this way: Rosenberg wasn’t really writing about the Chandler project, he was writing about software projects in general, using Chandler as an example to illustrate the principles of software development that he already wanted to write about!  So, if what you really want to know about is what actually happened on the Chandler project, this may not be the book for you.

On the other hand, if you want lyrical rhapsodies about how “public static void” can be read as a kind of machine poetry, and how the gap between zero and one is the gap between man and machine, by all means have a go at it.  (Those parts of the book are actually interesting and fun, I find.)  Just don’t make any assumptions about how these abstractions map back to the real people and real tasks of the real project used to illustrate them.