Software development dreams, nightmares

Work on a software development project long enough and you start to have dreams (or nightmares) about code. In his recent book, Dreaming in Code, Scott Rosenberg witnessed firsthand the struggles and successes of Chandler, a next-generation personal information manager project by the Open Source Applications Foundation (OSAF) that's expected to be released next month. Recently Rosenberg talked with about his observations, reaction to his book and the challenges of building quality software.

Author Scott Rosenberg
Author Scott Rosenberg
When you talk to a roomful of software people about your book, are they all nodding their heads in agreement?
I'm finding two basic responses. One is a nodding in agreement. The other reaction definitely is a kind of a pushback, which says I'm telling the story of a project that did everything wrong -- that "we know better and we do better all the time, and why should we bother reading about someone else's problems." It doesn't surprise me to get that reaction because the world is full of confident developers. Certainly with hindsight it is relatively easy to say, "Why did they do this? The mistakes are obvious." And yet my challenge to those people is to say, "Can you really say in your current work or all of your past projects you've done everything right?"

There are specific things that any project can do to increase the odds of success, like making sure there's a consensus on what the requirements are, finding a common vocabulary, working incrementally and getting stuff in front of users earlier rather than later. The challenge is in the collision between the awareness of those practices and the on-the-ground realities of a specific project. There are endless contingencies that can derail you from these good practices. How you deal with all of those things is how your story unfolds. Can you talk about some of the ways you believe developing software is unique?
It's got this dual nature. It is part engineering, in that you're creating something that has to perform a function reliably. The part that tends to be a little less understood or less honored, is the part that is more imaginative and artistic -- the fact that software is this pile of abstractions that is the product of human imagination.

The demands on software typically come from business, and business understandably seeks reliability and predictability; you want to know how long things are going to take. With software, the assumption is we should be able to do these things, and the surprise comes when we can't. If you account for this artistic or imaginative element, then you might be thinking about it more the way a movie studio thinks about a product. There are imponderables, and the industry accepts that and deals with that. [The movie industry] tries to limit that wherever possible because large sums of money are involved. But it's understood that there are imponderables, and in software we haven't accepted that and maybe we need to. Were there any surprises in what you observed about how the Chandler team members worked together or how they dealt with this project?
Chandler, and other projects I've seen, started in many ways from square one in terms of how are we going to proceed, how are we going to work together. This was an open source project, so there were some things that you knew from beginning. You knew that there was going to be a repository of code and that people would check code in and out, and that it would be available to the public. But there were other things, like what kind of approach to scheduling work and releasing versions, and how would this particular group decide on subdividing the work and who does what. It was surprising to me that this was figured out on the fly. You talk about the developers as being doomed, facing more bug fixes than they had time for. Besides bugs themselves, what are some of the other issues the Chandler development team had to deal with?
Probably the biggest one was the scope of the project. The original goal for Chandler was that it was going to be a new model personal information manager. It would be open source, cross-platform. It was going to be a fully featured client software application that would have a flexible and rich graphic interface, and it was going to be peer-to-peer. So you threw all that in at the beginning and for quite a while you had the team just trying to figure out how they could achieve all those goals. In retrospect, everyone involved that I've talked to looks at that period and says, "We probably should've been more cautious about how many of those big requirements we threw into the pot at that stage." Because of those ambitious goals, I think they had a much harder time just getting the project to the point where there was working version.

Read an excerpt of Dreaming in Code
Dreaming in Code tells the hidden story of the making of software -- specifically Mitch Kapor's Chandler. "Chapter 1, Doomed," provides a peek into the bug repairs for the Chandler project and how the team handles getting all its work done in the little amount of time left.
The other big challenge, and this is something that happens on projects, is coordinating the vocabulary -- finding ways to make sure that people doing the design work and people doing the back-end development and people doing the front-end development share a vocabulary and an understanding of what those terms meant. In Chandler's case, you had the situation where you had "items." You have things that the user -- and therefore the designers -- are referring to as "items," and you have things that the back-end developers are referring to as "items" and these things are not aligned. I have observed the same problem in other software projects. You wrote about the Chandler team using a wiki to help manage the project. What were some of the problems with that?
The danger with a wiki is its strength is also its weakness. The strength is it's really easy to add stuff and the barriers are few. But in the case of the Chandler wiki, the volume of information grew at a huge pace. "Wiki gardening" is a good metaphor; it requires constant gardening. They just did it again at OSAF, and the wiki is now much more approachable. They do a big refactoring of the wiki, and for a while it's in better shape, but then it begins to get unruly again. You end up with this big unstructured pool of stuff that somebody has to wade through. So is the "software is hard" problem really more about project management than the difficulty of programming?
Project management in general is a complex and often difficult undertaking, and that's true outside and inside the software field. But then there are particular traits that make software even harder. They're rooted in the abstraction of the work and how difficult it is to do. With programming projects there's all these attempts to find metrics for progress -- lines of code written, feature points -- and none of them really tells you what you want to know, which is how far along are you? And you can't even really know when you're done. What is being done mean? It's not a simple matter. After writing this book, are you optimistic or pessimistic about the state of software quality?
One principle I've come out with is be respectful of any system that works and is deployed. If it's there and it's working, disturb it at your peril; disturb it only because you have some overwhelming reason to disturb it.

Another is, I think you can't look at the last 25 years of the computer industry and not say there are things we're doing today that we simply weren't able to do at the beginning. And to me the great optimistic story, the story that certainly changed my life and that I think has changed a lot of lives, is the Internet itself. It's creating an amazing array of opportunities for people. It's an achievement -- it is cause for optimism. The fact that we're still struggling with bugs, and a lot of systems still don't work the way we want them to work -- that's all there too and we can't ignore it, but we shouldn't let that completely cloud over our sense of achievement. How did the Chandler team feel about the book?
I got two reactions from them and from Mitch Kapor, the leader of the project. Generally the reaction was this was a fair and accurate portrait of their work, so that pleased me. The other part of it, which is totally understandable to me, is they're not happy when they hear the book is sort of an account of failure. That is something some of the reviewers have said. It's not actually something I ever said in the book, because I think the jury is still out. There might be more to the Chandler story, but it wasn't going to illuminate the questions I was pursuing, and that's why I chose to end the story where I did.

Scott Rosenberg is Vice President of New Projects at Salon Media Group Inc. in San Francisco. He is a co-founder of, where he served as the first technology editor for the online publication, and then managing editor. Previously he wrote for the San Francisco Examiner, serving first as its theater critic, then as its movie critic and "digital culture" columnist.

Dig deeper on Software Quality Management



Enjoy the benefits of Pro+ membership, learn more and join.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: