I’ve not done much running before, but I’m training to run a marathon. I’m telling you this so you can ask me about it whenever you see me. And you should feel free to plaster me with insults should I decide not to follow through. Virtual accountability. But it struck me how similar this training process is to software development.
It’s about iterative improvement
========
Most runners get themselves into trouble when they try to train too hard—seeking to improve too much at one time gets you hurt. The real key to success is to improve by 5-10% every week. Software works the same way. Focus on a few users stories for next week’s demo instead of working toward that big bang integration a year from now. Baby steps, baby.
Part of the magic of Ruby on Rails for me is my ability to meet with my end users every week, and show them a substantial improvement in a weekly demo. Java didn’t work nearly as well for me in this mode because we couldn’t show demos at all in the early stages (we were working on infrastructure) and we couldn’t get the customers excited about demos every other week or every three weeks. Actually, in the early stages, with scaffolding, we could lay out some basic features very quickly, demonstrating:
- The underlying structure of the data model
- The basic flow of the user interface
- A real security model
In this marathon, I’ll succeed if I improve every week.
Leave enough time for recovery.
=======
If I don’t save enough time for my body and mind to recover, I won’t be able to withstand the pounding of the long runs. I might not, anyway. But if I take every fourth week lightly, and if I save three days after my short runs, I’ll have a much better chance to succeed with the whole race. You can’t work consistent 60 hour days over the long haul. Your employees can’t either. Don’t try.
You also need some way to break up a day. Throwing a ping pong table into the basement does wonders for your long term productivity by keeping your mind relaxed and fresh. Neal Ford is helping me build the training regimen. When I try to push myself too hard, I hear him whispering “Marathons are not about speed. They are about sustainable pace.” That’s a beautiful way to live.
Build in checks and balances
========
At some point, marathon training will be stressful enough for me to want to quit. That’s why most people train in groups. Succeeding to me will mean making an effort to record my runs in my training spreadsheet, bounce my training strategies off of someone who knows more than I do, tell people close to me what I plan to do so that I’ll be motivated not to disappoint them.
Agile software development is like that too. I lean hard on unit tests, close interaction with customers, and the fastest possible feedback loop. To support my refactoring, I integrate each time I drop code. I build test cases first. Building software without a series of checks and balances is crazy. Some mistake agile development for undisciplined development, but the discipline is there…it’s just not in the same places as it would be for a waterfall project.
Relax
=
If I obsess over time, or if I’m a slave to my schedule, I’ll hurt myself or get frustrated and quit. I need to be flexible with my training schedule. The nice thing about training for a marathon in 2006 is that there are plenty of schedules to work from, and plenty of training philosophies. But what works for Neal or my neighbor (she passed me with a baby stroller yesterday…humiliating…) won’t necessarily work for me. I need to tailor the process to fit my needs. Here are just a couple of examples.
- Most people say train with a group to increase motivation and accountability. But I have discipline to spare. I write books because I don’t mind putting words to the page until I am done.
A more difficult challenge for me is time.I need to be able to step outside the door and run, or I won’t finish. And I know this well. So I train by myself. - Most people have 9-5 jobs, and do long runs on the weekends. I travel with the http://nofluffjuststuff.com tour on many weekends, so I will likely start doing my long runs on Monday.
- I travel often, so my weekly run schedule is not fixed. I just need to make sure that I don’t run on back to back days, and that I do two short and one long runs a week, constantly nosing the distances up.
Too many people are slaves to their process. Dave Thomas says a development process is a starting point. I agree. If pair programming doesn’t work for you, don’t do it. If you can’t live without class diagrams, build them. And if you can’t get into the flow of test-first, code your test cases after the fact. By all means, tailor your process to what works for you.
But anyway
==
Ask me how my training went. Kick me in the butt when I slack. And send Codine. Lots of Codine.