Dreaming in Code

Yesterday I hosted the annual event for the CTO (Chief Technology Officer) and Vice President of Engineering executives from the East coast Sigma portfolio companies. This is an annual event, and something we also do for the other groups of executives in our portfolio companies. The West coast has similar programs as well.
Over the last couple of years we have held a "book club" as one of the discussion sessions, and this year we read Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg.

The title may be familiar to adult students of foreign languages. You know you are getting the hang of a new language when you have a dream in that language. One of the programmers in this book talks about dreaming in code...

This book is a great read, and opens up, even for the non-technical reader, a feeling for the reality of creating software. It is an ugly reality. We struggle between engineering and art. We like to think we can build software the way we build bridges, but there is no physics to constrain us or inform us. Our industry is full of stories of individual programmers who are 10 or 20 times more productive than the rest, who produce "beautiful" code ... surely they are artists.

And yet, getting artists to work together on projects is not generally an effort of science or engineering. In a section of a legendary speech given in 1968 on this very topic, we are invited to imagine a group attempting to write down the criteria for the design of the "Mona Lisa". Nearly 40 years ago this allegory highlights the same problems described in Dreaming in Code, for which we have no more insight today. If creating software is truly an art form, why do we not teach it as we teach other art, by analysis and critique of the great works that have gone before (not so many, in our case). How do we harness large teams of people to engage in such an artisitic endeavor? This always leads back to a very famous book, written in 1974 called The Mythical Man Month by Fred Brooks. He was the first to show, unequivocally, that adding more programmers to a late project makes it later, and who reminds us that no matter how many women are assigned to the task, bearing a child takes nine months.

Dreaming in Code reminds us that software is brittle (it breaks rather than bends when stressed). We are also reminded that any decision is better than no decision. Mostly we are reminded that any software created by more than one person is driven by force of will, by leadership, discipline and strong management. It is not something that can be done in a commune. The "obvious counter-examples" are the open source community of programmers around, say, Firefox or Linux. However our group yesterday was unanimous in believing that existing software, with clear and articulated design, architecture and style can be turned over to a communal effort for improvement. Starting from scratch needs the force of will that only a lone programmer or a small well-managed team can accomplish.