Channels ▼

Arnon Rotem-Gal-Oz

Dr. Dobb's Bloggers

Software Development: By the People, For the People*

July 26, 2008

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):

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.

And, finally:

 

  • 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."

Weinberg writes a short retrospective of the last 20 years. Here are some interesting quotes (again emphasis mine):

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

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 


Video