TITLE: Speed Training for Software Developers AUTHOR: Eugene Wallingford DATE: December 06, 2004 6:57 PM DESC: Speed work-outs are proven technique for running faster, even when it's seemingly all in fun. Can we learn a lesson from running that will help us develop software better? ----- BODY: In making analogies between software development and running, I've occasionally commented on sustainable pace, the notion from XP that teams should work at a pace they can sustain over time rather than at breakneck paces that lead to bad software and burn-out. In one entry, I discuss the value of continuous feedback in monitoring pace. In another, I describe what can happen when one doesn't maintain a sustainable pace, in the short tem and over the longer term. Not unexpectedly, I'm not alone in this analogy. Erik Meade recently blogged on sustainable pace and business practice. I was initially drawn to his article by its title reference to increasing your sustainable pace via the fartlek. While I liked his use of the analogy to comment on standard business practice, I was surprised that he didn't delve deeper into the title's idea. Fartlek is Swedish for "speed play" and refers to an unstructured way for increasing one's speed while running: occasionally speed up and run faster for a while, then slow down and recover. We can contrast this approach to more structured speed work-outs such as Yasso 800s, which specify speeds and durations for fast intervals and recoveries. In a fartlek, one simply has fun speeding up and slowing down. This works especially well when working out with a friend or friends, because partners can take turns choosing distances and speeds and rewards. In the case of both fartleks and structured interval training, though, the idea is the same: By running faster, you can train your body to run faster better. Can this work for software development? Can we train ourselves to develop software faster better? It is certainly the case that we can learn to work faster with practice when at the stage of internalizing knowledge. I encourage students to work on their speed in in-class exercises, as a way to prepare for the time constraints of exams. If you are in the habit of working leisurely on every programming task you face, then an exam of ten problems in seventy-five minutes can seem like a marathon. By practicing -- solving lots of problems, and trying to solve them quickly -- students can improve their speed. This works because the practice helps them to internalize facts and skills. You don't want forever to be in the position of having to look up in the Java documentation whether Vectors respond to length() or size(). I sometimes wonder whether working faster actually helps students get faster or not, but even if it doesn't I am certain that it helps them assess how well they've internalized basic facts and standard tasks. But fartleks for a software development team? Again, working on speed may well help teams that are at the beginning of their learning curves: learning to pair program, learning to program test-first, learning to use JUnit, ... All benefit from lots of practice, and I do believe that trying to work efficiently, rather than lollygagging as if time were free, is a great way to internalize knowledge and practice. I see the results in the teams that make up my agile software development course this semester. The teams that worked with the intention of getting better, of attempting to master agile practices in good faith, became more skilled developers. The teams that treated project assignments as mostly a hurdle to surmount still struggle with tools and practices. But how much could speed work have helped them? The bigger question in my mind involves mature development teams. Will occasional speed workouts, whether from deadline pressure on live jobs or on contrived exercises in the studio, help a team perform faster the next time they face time pressure? I'm unsure. I'd love to hear what you think. If it does work, we agile developers have a not-so-secret advantage... Pair programming is like always training with a friend! When a runner prefers to run alone rather than with others, she can still do a structured work-out (your stopwatch is your friend) or even run fartleks. Running alone leaves the whole motivational burden on the solo runner's shoulders, but the self-motivated can succeed. I have run nearly every training run the last two years alone, more out of circumstance than preference. (I run early in the morning and, at least when beginning, was unsuitable as a training partner for just about any runner I knew.) I can remember only two group runs: a 7-miler with two faster friends about two weeks before my first marathon last fall, and an 8-mile track workout the day before Thanksgiving two weeks ago. As for the latter, I *know* that I trained better and harder with a friend at my side, because I lacked the mental drive to go all out alone that morning. Now I'm wondering about how pair programming might play this motivational role sometimes when writing software. But that blog entry will have to wait until another day. -----