One side-effect of working in the software world is a tendency to use programming as an analogy for life. Just to prove this, when people ask why I do Pilates I use a couple of programming analogies about how the whole process works. Pilates is a method of exercise which I started doing after tiring of the way my knee would slightly dislocate when I walked. I’ve been doing it for about 2 years now and although I’ve sprained my knee since, it doesn’t dislocate any more (yes, this is progress!). Any decent Pilates studio (I go to Dianne Miller Pilates) will tailor not only the program but the way it’s taught to each individual’s needs. I’ve seen two categories of teaching, with distinct similarities to maintaining software.
First, there’s what you might call the fixing bugs mode (or maybe TQM if you’re more into acronym-filled BPR analogies). Strengthening the muscles around the knees in my case, and teaching my over-achiever deltoids not to do the work that the rotator cuff and serratus anterior muscles should be doing (lots of the Pilates philosophy revolves around making muscle groups do the work, not training individual muscles).
Eventually you’re far enough along the path that the instructors decide it’s time to change everything — somewhat like deep refactoring, or rewriting the kernel. So right now I’m working on changing the way I walk, and I’m back to doing the really basic exercises at Pilates in a different way. I’ve heard people who golf a lot talking about rebuilding their swing which sounds like a similar process, with similar trade-offs to deep refactoring. If you don’t do it, you don’t have any major performance gains. But reworking the way you walk, or the way you do exercises you’ve been doing for two years, or a program you’ve been fixing bugs in for five years, can be a big undertaking. Personally I think refactoring programs is easier than reprogramming muscle memory — software seldom spontaneously leaps back to the old version!