Dreaming in Code

One of the best books I read this year is called Dreaming in Code by Scott Rosenberg. I spotted this gem at the local public library sandwiched among some old books about Visual Basic and how to use Microsoft Office. The subtitle "Two Dozen Programmers, Three Years, 4.732 Bugs, and One Quest for Transcendent Software", definitely caught my eye. It is now available in paperback and is well worth the minimal cost.

As somebody interested in verification I had to find out more about how any project could work for 3 years and end up with over four thousand bugs. The book chronicles an open source project named Chandler. The project is still active, you can download the latest version and try it for yourself (but you should really read the book first before you try the software). More than just the details of the Chandler project, the book describes so many concepts of software development that are relevant for every project. The historical research that went into the book is excellent.

One night as I took a flight across Germany, I was reading about the age old debate on whether software development is an art or science. This is a small example of the ways the book will force you to think about software development, it's comes from one of the later chapters titled "Engineers and Artists":

If you report a bug to a programmer, the first thing she will do is ask, "Have you duplicated the problem?" -- meaning, can you reliably make it happen again?

This struck me because it implies the programmer would like to fix the problem by running a provided test case again and again (probably using a debugger) until the source of the bug is known. It made me think about how we work. Is the best way to produce quality software to iterate in a run, crash, run, crash loop until the source of the problem magically becomes clear? As a Minnesota resident, I witnessed the collapse of the I-35W bridge after I drove over it just a couple of days before. I wonder if a similar thing happened with the engineers of the bridge. When the collapse was reported to them did they as if the problem can be duplicated? Did they ask for a test case? Does this mean software development is not really engineering in the same way bridge design and construction is?

In the future I will share more of the great work in the book, how it has influenced me, and how it applies to software verification. If you have read the book please feel free to add your thoughts.