billpapa.org Reading (b)log

Dreaming in Code chronicles the troubled history of a software project (an innovative PIM application). It’s a very interesting book, both as an inside look of the development process, and as a great piece of journalistic writing. The team faced many problems and even now 4 years after the initial release, the 0.7alpha4 version is barely usable.

The interesting in this case is that the problems were not due to constraints. OSAF founder Mitch Kapor (of Lotus 1-2-3 fame) freely invested in his pet project, and there was no intense pressure to follow a schedule. The software is open-source, and the team included top 10% talent. Everything seemed to be perfect. What went wrong? “Software is hard” is a quote often repeated in this book, but was this the only reason for Chandler’s misfortunes?

An alternative explanation I might add from my perspective is this: it was precisely the absence of constraints that plagued the project. By constraints I mean two things:

• design constraints: the concept seems to have been quite vague, and mutated many times during design and development. That is normal and even desirable, but easy changes in high level specs show that there wasn’t much research on what this software should do in the first place. The absence of design constraints led to extensive and fruitless exploration of possibilities and yak-shaving.
  
• worksystem constraints: software development being a pure kind of knowledge work gets constraints from two sources - budget and schedule. In this instance, the team did not really feel any of these constraints; even the constantly slipping schedule was almost expected by the veteran developers.
  

Rosenberg highlights the fact that Linux was an explicit transcendence of Brook’s Law (Brooks, 1995) - because the low-bandwidth means of communication (forums, mailing-lists) lower the coordination costs suffered in traditional development environments. Also, in such an environment there is no manager push developers around, it is pure programming bliss.

The problem is that the OSAF team was organized to work the traditional way, and although they tried to be open as possible, it was clear that they were building a “cathedral” (but you could watch if you liked!).

I think the moral is you can’t have both ways: eclecticism does not work in this case. One choice is to organize the team as a Pole A worksystem -i.e. tightly coupled (Nathanael et al., 2002)-, by imposing constraints and some kind of (shallow) hierarchy and little if any outside intervention. Another way is to go open source all the way and have a Pole B (loosely coupled) worksystem. Oh, and some work up-front in user research doesn’t hurt either!

References

• Brooks, F. (1995). The Mythical Man-Month: Essays on Software Engineering (20th Anniversary Edition). Reading, Massachusetts: Addison-Wesley.
• Nathanael, D., Marmaras, N., Papantoniou, B., & Zarboutis, N. (2002). Sociotechnical Systems Analysis: Which Approach Should Be Followed? In S. Bagniara, S. Pozzi, A. Rizzo & P. Wright (Eds.), Cognition, Culture & Design (pp. 137-142). Sienna: Instituto di Sienze et Tecnologie dela Cognizione.
  
  

This entry was posted on Wednesday, February 28th, 2007 at 11:42 am and is filed under HCI, software engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.