Dreaming in Code by Scott Rosenberg documents the failure of the Chandler software project.
Chandler aimed to provide flexible information management. It organised emails and other data sources into a central object store. Intelligent features similar to Lotus Agenda’s “automatic assignment” aimed to predict semantic meaning from text, like automatically recognising events to add to your calendar.
Failure 1: Not knowing what you are building
The hard thing about building software is deciding what to say, not saying it —Brooks
Chandler’s team did not agree on how to build key components. This uncertainty became pervasive and spread to more decisions. The team wanted ‘more concreteness’ but could not achieve it. In retrospect, Scott comments that success requires firm choices to limit a project’s scope. Programmers can thrive under these constraints because it simplifies the problem.
Failure 2: Communication breakdown
Management is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant —Peter Drucker
The teams working on Chandler had multiple groupware systems for tracking project progress and communicating internally. This caused staying in the loop to eat up much of the workday. Developers drowned in emails, bug reports and wiki pages.
People tried to solve the communication problems by adding more resources to check. The author describes how a “heroic” additional glossary of project definitions, made to solve ambiguities, was abandoned unread.
Advice for the future
Information systems provide value when they interact with humans. Our world of information is not perfect, and any program is subject to having to connect to our imperfect world. Because of this, programmers should concentrate on solving the user need, instead of making a perfect technical solution for an imperfect world.
Communicating abstractions unambiguously — from programmer to machine, from programmer to programmer, and from program to user — is the single most challenging demand of software development.
Nobody should start to undertake a large project, you should start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it is likely is at that stage. Or, worse, you might be scared away by the sheer size of the work you envision. So start small and think about the details. —Linus Torvalds