I just came across an old article by Alistair Cockburn, called Characterizing people as non-linear, first-order component in software development that should be required reading for anyone working in software development. The title might be a little off-putting, but the message of the article is simple: It’s the people that make or break a project.
Cockburn first describes his own history in designing methodologies, and running into the same problems again and again:
- Problem 1. The people on the projects were not interested in learning our system.
- Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.
He then goes into a meta-study of different projects with different methodologies, and finds that:
- Almost any methodology can be made to work on some project.
- Any methodology can manage to fail on some project.
- Heavy processes can be successful.
- Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.
He then describes the well-known model of communication effectiveness, where the highest bandwidth communications (‘Two people at a whiteboard”;) is the most effective, and paper the least. He gives nice examples here:
Even walking from the train station together was a more effective design environment than talking over a video link.
This is then turned into practical advice on how to document systems: use video recording of a whiteboard sesssion, preferable annotated to indicate the ‘good bits’. This seemed like a lot of effort to me at first, but it might actually be easier then the normal paper trail, and should be a lot more effective.
Then, there’s some bad news: people are inconsistent! Shocking…
But that means that if you have high-discipline methodologies, for instance depending on religiously keeping documentation up-to-date, you’re setting yourself up to fail. Non of the projects he investigated managed to keep their documentation in perfect order. And even in those that came close, people didn’t trust it to be up-to-date, and always referred back to the code.
It is recommended to, instead of relying on the unlikely consistent and disciplined behavior of people, to instead depend on the success factors of people:
- people are generally interested in being “good citizens”,
- people take initiative,
- people are good at looking around.
In other words: You can’t make your documentation perfect, but people will simply take the initiative to look around and find what they need to know. Either by looking in the code, or by talking to people.
I think this is one of the reasons why I like agile methods. They are very much focused on people, and on creating an environment where people can work together, using high-bandwidth, multi-modal communication, and relying on their inherit strengths, instead of trying to force them to compensate their weaknesses.