When I first read the excerpts from the book Dreaming in Code I knew it will be an interesting read. The book chronicles the making of open source PIM application Chandler financed by Mitch Kapor. The idea was to create a world changing Personal Information Manager to manage emails, calendars, notes etc. Lofty goal which ended up being project like Chinese Democracy album Guns n’ Roses are still working on since 1994.

The book is really good read especially for developers and development managers. I am sure that anyone can relate to the things Chandler team went through since this stuff is really common throughout the software industry.

To me though, one thing stuck out. Without constraints almost any software project would run in an infinite loop. In most software projects constraint is money. There is only so long investors will keep on financing a project and team is pressured to deliver within certain time limit or go bust. In Chandler project though, the investor is wealthy and willing enough to keep it going for a very long time without project really delivering.

The financing though is not single constraint but it is usually a big one. You can see how no constraints approach has affected this project from selection of the development language/platform to the actual architecture. Without constraints we all want/need to make the really right choice. To make the right choice we need to investigate and evaluate all possible options. That takes time. In teams especially, people are careful about making a “wrong” decision so this process takes forever. Worst of all the choice that is made very likely is not really a good one either.

Most of the time good enough is really good enough.

For example, Chandler team spent lot of time choosing the right programming language for the project. They ended up choosing Python, but nobody on the team seemed to have experience with Python. However, that was not of a concern it seems, since there was really no constraint on project timing and they are all smart developers. At some point in project, after year or two, the little of the software they had written performed poorly. One of the Python gurus looked over the code and commented “Python is not Java“.

“I found they had done lots of things that make sense in Java, but which suck terribly in Python“. Well, duh! I see this repeated over and over again. While it is good thing to review the available technologies before starting project (I love doing that and I am personally guilty as well 🙂 ), one must be aware of the actual cost of using something that team is not experienced with. It is my belief that it takes 6-12 months for the developer to truly be productive on new platform or language. There is no way around it…

It is like seeing .NET component that modifies the static class members of StringFormat in .NET Framework and screws up text output for the whole application. You know right away that it was written by platform newbie…

Would things turn differently if Chandler team had chosen Java over Python, I doubt it, but maybe… Would they turn out differently if they had real constraints on their project scope and timing, I am sure they would.

All in all, really enjoyable read, I highly recommend it.