The Old School Manifesto
Mon, 10/11/08 – 22:08 | 2 Comments

As we saw in the last essay, the 80:20 rule seemingly appears in many circumstances. When I was attending college and working as a programmer during the 80’s, there were some commonly accepted tenets that guided our software development processes and behaviors.

Read the full story »
Management

Methodology

Metrics

Quality

Requirements

Home » Methodology

The Software Process Wars

Submitted by Bill Miller on Friday, 14 September 2007 No Comment

Software Process Wars

The Agile software development practices are in their infancy stage as evidenced by the number of variants that are being promoted in popular print and usage today:  Scrum and XP being two popular variants.  Clearly the Agile practices are still evolving, and I believe what will eventually emerge are a set of Agile practices that look awfully familiar to traditional approaches.  The question is, is once the Agile community arrives there, will the conflict cease?

My expectation is that it will not.  As the Agile approach converges with traditional approaches, the Agile zealots will declare that they’ve been abandoned by name the popular evil - corporate types maybe.  The other more important reason that the debate will fester is software projects will continue to fail with both approaches.  This fact will only continue to fuel the Agile zealots’ fire that they’ve been abandoned, and if teams would only adhere more rigorously to the pure Agile tenets, projects would not fail.

Reading Wars 

Much of the friction between the Agile camp and the Traditional camp is reminiscent to the Reading Wars that are being waged across America and internationally.  The traditional approach to teaching children to read advocates a phonics approach.  After all, the written alphabet was designed to encode sound.  It only stands to reason that to read requires a person to learn the encoding rules and to decode the written word.  That’s how I learned to read.  It certainly works.

The modern advocacy to teaching children to read is with a process called Whole Language (don’t the issues sound a lot like Agile?).   The theory is that reading should evolve from print like speaking evolves from hearing.  No one instructs a child directly with the rules of the spoken word.  Children learn to speak through trial and error while immersed in spoken language.  Likewise, immerse children in the printed language, and children will learn to read almost intuitively.  It sounds nice on paper.

One of these two approaches to teaching children to read is the best approach.  Where the inferior approach has got it all wrong is that failure for children to learn to read well has nothing to do with the approach that was replaced.  The child’s God given ability is a more important factor in success or failure to read well, and so we argue and debate about the reading process that had nothing to do with failure.  A good process ends up being replaced with an inferior process contributing to more reading failure, but the people cornering the debate are unwilling to explore the possibility that they’ve introduced something that doesn’t work.

Similarities 

In many ways the issues in the Reading Wars parallel the Software Process Wars:

  • Children have learned to read with both approaches, and software projects have been delivered with Agile and Traditional approaches. This is why the debate never ends.

  • Children who are the most successful readers with the Whole Language approach are the smartest children. Agile proponents require the team to be highly capable for success. Having highly capable people on a team is great and important, but it’s impossible to build an organization with only extremely talented people.

  • Children fail to read well with both reading approaches. Software projects fail with both Agile and Traditional approaches. Sometimes failure has nothing to do with the process, and sometimes it has everything to do with the process.

  • The Whole Language approach is built upon a flawed premise: decoding skills do not need to be taught directly; they evolve through immersion in the printed word. The Agile approach is based on a false premise: waterfall phases can be ignored and don’t apply.  A flawed theory is normally built upon an incorrect premise.

  • Whole Language success requires higher skilled teaching professionals.  Agile success requires higher skilled engineers and management.  It’s impossible to build an entire organization with only top talent, and it is not even advisable.  A mixture of ability makes for a succesful team; though, having no standard for minimum ability is bad.

Conclusion

Fundamentally, the reason the Reading Wars and Software Process Wars will continue unabated is there will always be failure with either approach.  Where the promoters of the inferior software paradigm have it all wrong is that in many cases failure has nothing to do with the process, it has everything to do with the quality of the people leading and working the project and organization.   People issues are difficult problems to fix and to talk about, so people debate what’s easier to talk about and change.  In fact, many people recommend new processes as a solution to fix people problems when that only seems to exacerbate problems as I can’t recall a case where a change in process made things better when the wrong person was responsible for the job.

It is my plans to discuss the people and management issues that impede project and team success.  I don’t profess to have all the answers, but I plan to present what’s worked well for me and what I’ve witnessed work well by the people I’ve reported to.   Some of the topics I plan to touch upon are organization structures, rewards, making change happen, and performance feedback to name a few.

Email This Post Email This Post Print This Post Print This Post
Vote This Post DownVote This Post Up (No Ratings Yet)
Loading ... Loading ...

Related Articles:

  • Why Software Process Adoption Fails
  • Danger: Agile Practices at Work
  • Agile Isn’t a Process
  • What Methodology Do You Follow?
  • Upfront Analysis Saves Time

  • Leave a comment!

    Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

    Be nice. Keep it clean. Stay on topic. No spam.

    You can use these tags:
    <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

    This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.