Software Development: By the People, For the People*
CrossTalk: The Journal of Defense Software Engineering, just published its August 2008 20th anniversary issue. This issue includes a couple of very interesting articles -- Good Old Advice by Alistair Cockburn and What Have 20 Years Accomplished and What Is Left to Accomplish in the Next 20 Years? by Gerry Weinberg.
Cockburn explains very eloquently something I also wrote about a year ago that the ideas and lessons expressed in literature of yore are not just valid today but they drive home the points of the "coolest" ideas we have today. Alistair does that by demonstrating how the principles behind the agile manifesto builds on the works of Fred Brooks, Barry Boehm, TomDemarko, Gerry Weinberg and many others.
<>We have known for decades that is is all about people , users, communications between them. Alistair summarize his article as follows (emphasis mine):
Weinberg writes a short retrospective of the last 20 years. Here are some interesting quotes (again emphasis mine):
I derived the four values of the Agile Manifesto from much older, recognized, and highly reliable articles. The point I wish to make is that the authors of the Agile Manifesto did not throw out all previous experience as they wrote it. On the contrary, what they did was cherry-pick four of the most important issues from among hundreds. The appropriateness of their selection is seconded by decades of prior experience and data, as evidenced by the numerous articles referenced in this article.
For decades, we have learned, documented – and ignored – the same lessons:
- Attend to the individuals and their interactions.
- Put the mercilessness of running software to good use – write, and learn from the writing.
- Get inside the heads of your users and customers, and get them on your side.
- Plan coarse-grained long term and fine-grained short term, and find a way to replan quickly – because you’ll have to.
- Do not believe in any single process or methodology because each works only in a particular and limited context.
Those who do not learn from history are doomed to repeat it. Let’s stop pretending we don’t know everything and let’s stop repeating painful history by following this good, old advice."
Individual managers, however, have certainly improved. The good news is that we now have many more excellent managers who can mentor new managers. The bad news is that because the field has grown so much, there simply are not enough experienced managers to go around. We still see people abused or poorly used by their managers. All of this in spite of the fact that we have much more information about how to work with people in software development – information that, sadly, is frequently ignored. Too many managers have failed to learn that the world will not end due to a late delivery or a defect in production. Nor have they learned to relax, breathe, learn from their mistakes, and try again.and
The idea of certification is only one of the management myths that has not changed in a generation. We still have an excess of heroic environments, often leading to death march projects. Many managers still maintain the fallacious perception that quality can be tested into slapdash software. Some still try to develop software without being bothered by potential users of that software. And some still believe that process models are the answer to all of our problems.
These are the things I notice on my pessimistic days. On my optimistic days, I notice more managers realizing that it is the people who make a difference, that they can hire talent, but then must also build the relationships to build a team. Quite a few organizations are now using process models successfully, but as only one of the tools providing information for informed cultural changes to their software community.
Though looking from different angles, both articles somehow hash the same ideas like "work iteratively", "be wary of magic or single processes" etc. I do believe that what underlies both these articles -- and, indeed, software development itself -- is that at the end of the day software is developed by the people and for the people, and we should not allow ourselves to forget it.
*with pardon to Abe for the misqoute