When Dreaming in Code was first released, it sparked my interest, but I shelved the idea after reading a few online excerpts. Its content seemed to be a rehash of my own career experience, thus I concluded that it would be bereft of any insight. However, when author Scott Rosenberg offered a free paperback version to anybody who would post some feedback on the book, I took him up on the offer. When I returned home from attending to some errands on Saturday evening, a package was lying on a chair in my den. Within 24 hours, the content of Dreaming in Code was digested and as promised, here are my nuggets of contributory feedback.

Ostensibly, Dreaming in Code is a tale about an ill fated group of software developers and their quest to create a revolutionary personal information manager (PIM), a calendar/email software package that didn’t suck like Microsoft Outlook. Mitch Kapor, of Lotus 1-2-3 fame captained an all star development squad that Rosenberg was given access to and tracked over a period of 3+ years. Intertwined with the tale of Project Chandler, is a general glimpse at the history of software development and how paradoxically, as computing machines grow more powerful, new expressive programming languages that abstract machine instruction have flowered, the complexity of building software has not diminished and is just as difficult as it ever was.

As mentioned, as I read through Rosenberg’s account of Chandler development, it was easy to relate to my own past experience. My beginnings in the field date back to the “dinosaur days” — when I began my programming career, the department was titled “Data Processing”, not Information Technology, and my first manager still did his coding via punched cards, and was unfamiliar with the usage of a text editor — but now stretch into the 21st century where I earn a salary as a web developer. So I’ve been involved in many a software project, some successful, some not, and some that qualify as “death marches”. As I read, these are the significant thoughts culled from the material:

• The Open Source Applications Foundation (OSAF) was staffed by some super smart minds. Kapor, creator of Lotus 1-2-3, along with heavyweights renowned from past glory at Apple and Netscape. Yet they all floundered and grew frustrated at the project pace.

• Some of the technical architecture decisions made I found quite odd. Like picking Python, a scripting language, for developing a client application. Python makes perfect sense for a web application, server side tasks or as a package customization extension tool. For desktop software, at least at the time when the Chandler effort started, I can’t think of a single smashing success story where a scripting language was employed client side.

• Also, from feedback elicited from developers by Rosenberg bore out that the Chandler programmers working in Python weren’t totally conversant with Python, and may have been writing Java (or other language) in Python. Consequently, they were nullifying the higher order advantages of a programming language like Python. And from my own personal history, I would never embark upon a major software construction project with lead developers not fluent in the project’s adopted language.

• While Kapor fronted the money for Chandler, according to Rosenberg, he was very democratic about how the project direction evolved. It seemed that developers planned and plotted according to Kapor’s vision, but Kapor restrained from authoritarian edicts in lieu of an organic approach. Perhaps the project would have been better served if there was a definitive proclamation from Kapor on the form of the desired deliverable. Again, as staffers joined and departed, the project roadmap veered into the leanings and predispositions of the developer du jour. Granted, at the source code level, this is understandable, but when it applies to database platforms and other critical juncture type decisions, it’s too much twisting.

• As Rosenberg noted, Chandler development occurred in a peculiar time window — after the dot com bust but before the Web 2.0 explosion of AJAX and cloud computing applications that Google and other wunderkind startups have been tossing our way the past few years.

• Finally, I wonder how much of a factor of just plain “being hungry” is. While the Chandler team was devoted to their work, Rosenberg doesn’t portray them as working incredible stints of overtime and pushing hard to close the gap between releases. Not that I believe programmers should be devoid of a life and devoted 24/7 to cranking code, but it’s not unreasonable to expect stretches where the team lives and breathes code in pursuit of a milestone. In fact, looking back over past project experience, I remember fondly those periods. Sure, it’s a problem if such a state is to be sustained over more than a couple weeks, but it was a burning focus. And while I understand the idea of a software creator proving that the first time wasn’t some crazy fluke, it’s just not the same as the team of young arduous programmers working feverishly on a new startup, living off of a credit card. Or a young programmer, fresh out of school or self instructed, eager to prove his mettle.

Rosenberg is a gifted writer — as I flipped through the pages, my head was nodding in agreement. But in this case, he’s speaking to a programmer already acquainted with the questions posed. I’m not certain that the material would appeal to the non-geeky. And there is little here that is new or noteworthy. The melding of the Chandler story and the 10,000 feet overview of software construction history shortchanges some questions that I would like to see explored in greater detail:

• Study of successful project efforts. While the majority of software build efforts are plagued by cost overruns and missed project deadlines, there are plentiful success stories. What about Paul Graham and Viaweb? Microsoft Excel? Or the modern 3D Massively Multiplayer World of Warcraft game by Blizzard. What did they do differently? How much of “success” is due to being at the right time and place?

• Small teams vs. large teams. Yes, large teams are burdened with the exponentially growing networked relationship tallies (aka Brooks Law), but isn’t there an inherent bias in our perception, given that if a small team (or lone maverick individual) fails, it’s not likely to draw notice, whereas a large team failure is a colossal misfortune of misapplied monies, wasted personnel, etc.… And are not small teams handicapped by a knowledge gap?

• What about the psychology of computer programmers? This topic was briefly touched upon in the book, but it’s a rich one that merits more research. Is there a special “programmer” personality? From past reading, I remember tales of how programmers were recruited back in computer infancy days — how math wizards, those with chess playing aptitude, card players, puzzle aficionados, housewives, etc.… were sought as programmer solutions. But there wasn’t a simple formula that could be employed — just that some people had a knack for it and some didn’t. Or study on how to foster harmonious relations between the programmer and the non-technical designer.

• What set of tools are needed to close the gap? Rosenberg discusses Microsoft legend Charles Simonyi and his Intentional Programming concept, but are there more practical, incremental steps that can be taken? What is the state of educational research on this topic?