I just read a couple of interesting Salon articles about Scott Rosenberg’s book “Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software” which tells the tale of OSAF’s Chandler project.

The excerpt “Words Fails Us” describes the classic naming problem we face when writing software. We name a concept before we’ve precisely defined it and as the code and designs evolve definition can drift, even when the team had a single concept to begin with. Naming is important, which is one of the reasons software re-factoring tools have become popular. Software is language. Once we precisely define things, they exist. One solution to the software challenge is to work in teams small enough that you can resolve communication problems without a glossary on the wiki.


Andrew Leonard’s interview with Rosenberg “Software is hard” talks about the underlying theme of the book. I guess it isn’t really about the Chandler project, but about all software projects gone awry, which, I suppose, is about all software projects. They all go awry, every day, in unexpected, amusing and frustrating ways. While the struggle resonates with my experience, I found myself startled by disagreeing with a few points that Rosenberg presents as accepted facts:

“And programmers, as I quote Larry Constantine in my book, programmers are programmers because they like to code — given a choice between learning someone else’s code and just sitting down and writing their own, they will always do the latter.” This “truism” is in stark contrast to the “programmers are lazy” adage. Most engineersI know who are looking for a compression algorithm or encryption technique will go dig up a popular library, rather than implementing their own. No one needs to prove that they can write the very best TIFF to PDF converter if there’s some available, already working code that does that. Perhaps this has gotten more prevalent with the rise of open source, and certainly web technologies tend to leverage existing shared code more than traditional software development. When it comes to innovation, reuse is hard, if not impossible, hence the challenge of writing new software.

“There is this raw fact in the field that the best way to create software would always be to have just one person write it.” A significant caveat to this “fact” is that the one person must have a complete and accurate vision for what the software needs to do, which usually only works well when that person is both author and audience. I do think software is best developed when there is a lead developer who can keep the whole system in his or head, but it helps to have other co-creators who can validate that you are building the right thing.

Although I may nit pick with some of his points, it is always interesting to see someone try to capture the struggle that of the software development experience — maybe when it comes out in paperback, I’ll read the whole thing. I am always amazed at how we consistently set out to do something novel, that we’ve never done before, somtimes somthing that no one has ever done before, and that we expect to be able to accurately predict how long it will take. I do believe software is challenging, but I swore to myself when my son was 3 weeks old that I would never again say “software is hard.” It is amazing how problems can be simplified and creative solutions can be envisioned after a good night’s sleep.