alex.moskalyuk

I finished reading Scott Rosenberg’s Dreaming in Code the other day. A story about Chandler project by Open Source Applications Foundation and Mitch Kapor, the book, written by a non-engineer, really tries to provide perspective into software development world and tries to help the reader understand why software projects fail. Through some anecdotal evidence, we mainly find out about large publicized government software project failures. Most of the private failures remain undisclosed, as within large corporations projects never fail, it’s just their resources that get “re-allocated to higher priority projects.”

While Chandler is not a spectacular failure by itself, the book does talk about a few steps that were taken perhaps in the wrong direction. So can this knowledge be summarized into distinct no-nos for anybody participating on a software project?

1. From development project to integration project. Engineers like the concept of reusability, and so do their managers, for whom the the choice between developing their own in-house product, or using a third-party (sometimes open source) solution, is usually straightforward. Unfortunately, few pieces of software integrate smoothly, and if you decide to go with third-party or open source solution, most likely you do not have people with complete expertise in it. Not to reinvent the wheel, engineers of Chandler project were discussing Zope Object Database, but as the product requirements changed in the planning stage, so did the requirements towards ZODB. No one on the team was a ZODB expert, so most of the discussions required further “looking into” ZODB internals.

2. No agreement on final architecture, or inability to settle on one. This seemed to be the case with Chandler team, all consisting of superstars. Having a dream team for the project has one disadvantage - everybody in the team respects the opinions of the others, and if dissenting views are presented, occasionally it’s hard to move forward without hurt feelings. Sometimes people in the room are thinkiing “I disagree, but what do I know”, leaving the discussion up in the air with no decisions made.

3. Feature creep. One of the problems that Chandler had outright was its need to be revolutionary, which required a redesign every now and then. As more things were abstracted (an “item” could be an e-mail, a note, a task on the to-do list, an entry in the address book, etc.), there were more features to add into the product making the next release unattainable. In the software industry, the term feature creep refers to more requirements entering the scene, making a release a highly unlikely event.

4. Poor reusability. Most of the engineers who have been working in the field for a while probably keep a personal library of routines they reuse over and over. So code reusability on a personal level is pretty good. Code reusability within organization is sometimes pretty decent, depending on how the CTO or VP of Engineering sets up the code repository and what practices are followed. Code reusability in the open source world is pretty poor. Even though there are quite a few well-written libraries out there that integrate well with other’s projects, most of the stuff requires heavy customization, if you’re lucky enough to get it in the language that you need. However, Dreaming in Code maintains that perhaps the reason you started writing your own project was to develop some new technologies, not to combine the existing ones into a single package. Therefore integration pain is the price that has to be paid for a final product to be worthwhile.