Dreaming In Code

book by Scott Rosenberg about OSAF in particular, and the general frustration of all parties in building software. Software Engineering, Big Project, etc.

http://www.dreamingincode.com/

The manuscript was turned in in late 2005! The Book Publishing crowd has to do better than this.

Scott Rosenberg blog post on progress at OSAF in the last year.

• he linked to recent Katie Parlante post listing specific accomplishments. The Preview release around April 2007 (described below) should be a good release for people to try out Chandler and Cosmo for the first time.

  • We're going to host Cosmo (the Calendar server) as a free service starting in March or April (when Preview is ready).

• he also linked to a June'2006 post about finally taking the [approach](http://wiki.osafoundation.org/bin/view/Journal/Process Description) [of](http://wiki.osafoundation.org/bin/view/Journal/One Dot Zero Target User) Fo Cus-ing on some Persona-s and User Scenarios.

My summary

• it doesn't really "sing" to me - the sections specific to the OSAF project itself are too soft/fuzzy/general. So, while it touches on lots of issues that come up along the way, you don't really get any depth of insight into it.

• but if you're a non-techie interested in the world of software, it's probably the best way to get a little glimpse into a specific project while placing that in the context of the history of computers, software, and attempts at improving complex systems.

• and if you've fallen into the programming profession, and haven't read Fred Brooks or Jerry Weinberg, etc., then this is probably a good book to start you getting more into the Culture.

Joel Spolsky review (Joel gets a couple pages in the book)

• Scott Rosenberg's excellent new book, which was supposed to be a Soul Of A New Machine for the hottest Open Source Start Up of the decade, ends up, in frustration, with Scott cutting the story short because Chandler 1.0 was just not going to happen any time soon (and presumably Rosenberg couldn't run the risk that we wouldn't be using books at all by the time it shipped, opting instead to absorb knowledge by taking a pill).

• Number two, you hired programmers before you designed the thing. Because the only thing harder than trying to design software is trying to design software as a team. I can't tell you how many times I've been in a meeting with even one or two other programmers, trying to figure out how something should work, and we're just not getting anywhere. So I go off in my office and take out a piece of paper and figure it out. The very act of interacting with a second person was keeping me from concentrating enough to design the dang feature. What kills me is the teams who get into the bad habit of holding meetings every time they need to figure out how something is going to work. Did you ever try to write poetry in a committee meeting?

• The only concrete design ideas, as far as I could tell from Rosenberg's book, were "peer-to-peer," "no silos," and "natural language date interpretation." This may be the a limitation of the book, but the initial design sure seemed to be extremely vague.

• Indeed, I think the idea of "No Silos" is most appealing to architecture astronauts... This is usually a terrible User Interface design technique. The way you make users understand your program model is with Metaphor-s. When you make things look, feel, and most importantly, behave like things in the Real World, users are more likely to figure out how to use the program, and the app will be easier to use. When you try to combine two very dramatically different real-world items (email and appointments) into the same kind of thing in the user interface, Usability suffers because there's no longer a real-world metaphor that applies.

  • I'm not sure I agree with this at all. (Object Browser)

    • LifeStreams certainly took a limited approach to this with some success.

    • though I agree that trying to map an EMail (message? thread?) to some other object type is always going to lead to headaches, because (a) it probably maps to multiple other objects, and (b) you don't want all the background schmutz that comes along with the narrative of email.

    • so maybe what you want is an easy to way to spawn linked objects, keeping visible Two Way Links everywhere, so that you can jump from a To-Do List item to the email that generated it, to the Calendar entry with the meeting to discuss it, etc.

The book notes that OSAF has many more Women managing than most software organization. Ouch, not a great case-study to encourage more of that...

Dec'2007: Mark Bernstein [gives](http://markbernstein.org/Dec0701/Dreaming In Code.html) his perspective. Chandler sure scared me, since it was announced shortly after Eastgate committed to Tinderbox, stems from one of the same inspirations - Kapor's Lotus Agenda - and sought to address some of the same problems. Because Chandler overlaps so much with TinderBox, I find it difficult to write about the project with confidence... What Rosenberg doesn't capture - because Chandler seldom captured it - is the way software actually gets written: in slow, steady segments, in dashing sprints, in long nights of inspiration, in weeks of staring at the screen, but always - in the end - by one or two people working to get something to work. In practice, this usually means one or two people imagining how it might work, and then making it happen. There wasn't enough of this in Chandler, and when it did happen, it too often happened to infrastructure, deep in foundations that were expected to underpin grand structures that were never built.

Alternate semi-related book: novel The Dead Line by Tom De Marco.

Boy, I hope there's an embedded writer at OLPC.