November 22, 2006 - Give it up for fallibility

If there's anything I've learned from adopting agile software practices and working at a company that embraces them, it's to have respect for fallibility.

No human software development activity can assume perfection. Perfection requires perfect knowledge and perfect rationality, neither of which is attainable. (Okay, so maybe you have perfect rationality, but try not to admit it too loudly.)

Where does perfect knowledge forsake us?

Imperfect rationality is no less cruel:

The waterfall methodology was designed with a worthy goal in mind: do it right the first time and save effort. When software professionals achieve super-humanity, the waterfall methodology will reign again. Until then, we're stuck with more humble methods:

  1. Recognize that no model, person, tool, or process is perfect.
  2. Maximize and speed up feedback to detect and recover from stumbles as quickly as possible.

This, for me, is the crux of agility. This isn't a new idea, of course. As Martin Fowler wrote in his New Methodology essay, one of the two key differences between Agile and "Monumental" methods are that "Agile methods are adaptive rather than predictive." (Fowler also refers to other precedents in iterative development methodologies.) But it doesn't hurt to be reminded of why agile works when monumental fails, and what lofty preconditions monumentality requires.


Posted by Ken Koster at November 22, 2006 11:22 AM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/231


Comments

Embrace change!

Well said.

Posted by: Kevin on November 22, 2006 12:45 PM