Writing software with the grain

Exploring the humanity of Agile methods

1 2 3 4 Page 4
Page 4 of 4

Iterative development

Waterfall projects required us to be good at predicting the future. Not only did we need to know the requirements of a product that wouldn't come to market for perhaps another year or more. We also had to know how long it would take us to build features we wouldn't become closely acquainted with for months. We were asked to be prophets of the highest caliber, and we know how well this worked out. Humans are notoriously bad at knowing the future.

We're gifted, however, at wanting to know the future. Wanting to know which horse will win, when our stock picks will peak, whether our project plan will be accepted, or whether she'll say "yes" is as human as it gets. We expend significant effort devising means of making good guesses about the future and coming up with the most likely predictions. Depending on the kind of thing we're trying to predict, sometimes we enjoy modest success, but usually our odds are no better than random. This never seems to stop us from trying again. Nothing will keep us from playing soothsayer.

For Agile simply to wallow in the unrewarding human passion to know tomorrow before it happens would not be much of a help. This is, on balance, an unproductive tendency we humans have, and it is one to be minimized if possible. Agile helps us manage it by acknowledging our poor performance as diviners and imposing on us constraints about how far out we may look. It does this through iterations.

Iteration planning still requires us to predict things we can't yet see, but it specifically prevents us from looking out too far. By keeping our would-be prophetic vision on the next couple of weeks, it focuses us on things we know better -- that is, the user stories we've already thought about and that are already functionally related to work we've done recently -- and reduces the future uncertainties about which we must guess. It recognizes the bad results we normally get when we prognosticate, so it keeps our prognostications to a bare minimum. Through the structure of iterations, Agile is circumspect about our ability to know the future. While denying us our desire to predict might seem cruel, this constraint is in fact deeply humanizing, because it respects the limitations inherent in the people who plan and execute software projects. On this account, Agile helps save us from ourselves.

Human, not superhuman

A word of caution is in order, lest I make my point too strongly. Too often, discussions of Agile methods lend themselves to a breathless tone and an air of utopianism. Proponents of Agile sometimes sound as if we just figured out how to write software in early 2001; that all projects undertaken before then were classic Waterfall projects; that all Waterfall projects must have been failures; and that Agile will soon cure the software crisis, world hunger, and Simon Cowell's temper. Prior methods weren't a thorough success -- hence Agile's emergence and enthusiastic uptake -- but the work of the two generations of brilliant programmers and managers who preceded Agile's birth is not to be lightly cast aside.

Agile is a better development methodology than Waterfall, but it's no silver bullet. It is the right paradigm for right now but not the last Big Idea we'll have about how to build software. Paradigms will eventually shift again, and we can trust future thought leaders that the next paradigm will be an improvement over what we are doing now.

We should be modest about Agile's finality, but we shouldn't let that modesty stop us from recognizing what is true about it. By directing us to tell stories about software, preserve knowledge in groups first and documentation second, and keep our predictions to a bare minimum, Agile works with the grain of the human beings who give life to development projects. The human grain is a noble one, and life is better for our teams when we respect it.

Tim Berglund is an independent consultant who loves to help his customers be the best they can be at Web development on the JVM. He enjoys architecting and developing Java- and Groovy-based systems using Agile methods, and training and mentoring teams to do the same. He blogs at www.augusttechgroup.com/tim/blog, and is on Twitter as @tlberglund. In his spare time he pretends to be a liberal arts major.

Learn more about this topic

  • The Manifesto for Agile Software Development states the principles that underlie Agile methods.
  • In "The New Methodology" (Martin Fowler, martinfowler.com, December 2005), Fowler -- one of the signers of the Agile Manifesto -- explores the reasons for Agile methodologies. Among them is "putting people first."
  • Agile's antithesis is the Waterfall model.
  • Waterfall was alive and well at the (fake) Waterfall 2006 conference, which included (fake) sessions like "Work Harder, Not Smarter" and "Introduction to Dogmatic Programming."
  • "Agility meets the waterfall" (ShriKant Vashishtha , JavaWorld, March 2008) offers practical ways to embrace Agile methods, even if you work in a Waterfall shop.
  • The Agile Alliance is a community that support the values and principles of the Agile Manifesto and organizes the (real) series of Agile conferences and other events.
  • Nouns crush verbs in the Java language, according to "Execution In The Kingdom of Nouns" (Steve Yegge, Stevey's Blog Rants, March 2006) -- a great example of how a language's "wood grain" affects the programs we write.
  • The Turing machine, described by mathematician Alan Turing in 1936, is an abstract device that can be adapted to simulate the logic of computer algorithms. The operation of all digital computers can be described using Turing's model.


1 2 3 4 Page 4
Page 4 of 4