Running and software development

I have a long love/hate relationship with running and I think that it's a great metaphor to help explain the subtle differences between agile practices and traditional development. My kids have been bitten by the running bug and they devote a lot of time to cross country and track. More importantly, they have trained for running longer distances and therefor better understand the importance of preparation, pace, and form.

As a person who spends a lot of time playing soccer, the idea of NOT running as fast as possible still requires a LOT of mental energy. On the rare occasion that I still get out running longer distances with my kids, they routinely tell me to slow down for the first mile... then they scratch their heads because I burned myself out blazing through the first mile in 7-8 minutes.

In software development, agile practices are the equivalent of the type of running done in soccer... you are actively changing direction, reacting to things on the field and using strong, explosive, but short bursts of energy. Scrum actually borrows metaphors directly from rugby to help explain the activities and practices (Rugby being a form of European football closely related to Association football from which Soccer derives its name).

More traditional linear development process and practices are more like running distances, where pacing yourself, conserving enough reserve energy to make the entire distance is more important than getting 40 yards ahead of the competition as fast as possible. Iterative or Agile processes are more like Football (soccer, rugby, american, austraian rules) where explosive movement and short timings are more important than endurance and predictable splits.

There is a place for both approaches, but too often folks want to try and do BOTH at the same time and it just doesn't work. It's a bit like trying to sprint a marathon while chasing a ball... it's just not going to work.

Comments

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

The difference between Scalability, Performance, Efficiency, and Concurrency explained

the myth of asynchronous JDBC