Running and Software Development

What can running and software development have in common? Nothing special at fist glance. A sweaty and slender runner totally differs from a flabby, bent by scoliosis programmer. Stadiums don’t applaud to developers and no one gives them the country flag for the lap of honor round the office after some release. Nevertheless, running and development do have many things in common. I have read a very difficult book — Surfaces and Essences. Douglas Hofstadter had a blast and I didn’t want to read the book after the first 50 pages. I literally forced myself to read few dozens of pages per week until I read till the third book – then I loved it. This book is about the way people think. They think in terms of analogies. Using millions of examples, Hofstadter and Sander quite clearly bring out the way analogies work and the things you can achieve with their help. And a great idea came to my mind. I decided to take one area of knowledge, analyze it and apply to another area. I chose running. To begin with, let’s review running qualities and analogies that can be drawn with development.

That’s what I got.

Running	Feature delivery	Running direction	Development direction	Distance	Release	Running speed	Feature delivery speed	Staying power	When will I be sick of it?	Traumas	Traumas

Perhaps, you have questions like “what does this odd dude mean by development direction?” and “what bloody traumas can programmers have?” It’s really good as it means that there’s an intrigue and you’ll at least run your eyes over the pictures. What’s the goal of running? I would say it’s to> Run as fast as you can and as far as you can without traumas

A runner at the hundred meter race will laugh into my face as he doesn’t have to run farther. But any middle and long distance runner will nod in approval. If you have ever run, you know how it happens. At first you run 2 kilometers with 6:50 result, then 5 kilometers with 5:30 result, then 10 with 4:50 and finally you drop running due to problems with your knee/heel/ankle. Every time you go for a run you want to do it faster and farther than the previous time. Let’s move on to software products. Here we want to > Develop as fast as we can and as far as we can without traumas.

Professional runners do know how to gain their object. Let’s see what we can learn from them.We’ll take running features and generate new hypotheses which can be tried out in development. #### Direction

You have to run in the right direction. It’s such a trivial thing in running that no one ever thinks of it. It’s hard to imagine Usain Bolt placing the starting blocks and running to the stand. Or how in the middle of eight hundred meters Wilson Kipketer would wheel around and run away, followed by baffled hum of the stadium and surprised eyes of contender.But it’s quite common for hardware development. Thousands of products have been developed and no one needs them. Almost every product has features that are not in use. They might have an excellent code inside and a great architecture, but nobody cares. Developers of these products have been running in the wrong direction. The choice of the right direction in products development is an extremely difficult task. Everybody makes mistakes. The insight doesn’t work. Collective mind gives out astonishingly wrong decisions. It’s hard to build a formal model. Even experience helps by no means always. Unless we reach the wrong place faster. But nobody’s waiting for us there. What can we do in order to choose the right direction? Create fast prototypes and verify conceptions. Build simple models and consider user behavior patterns. Fill the system with statistics and learn to understand which features are in common and which are in rare use. There are many solutions and none of them is perfect. It’s extremely important to realize that direction choice is the most essential thing in development. If it’s right — we’ll enjoy our vacation by the sea sooner or later. If it’s wrong —we’ll spend long and rainy nights at home. #### Distance

There are plenty of different distances in running, but they can be divided into three types: sprint, middle distance and marathon. Type runners differ from each other. Here’s a funny video which explains everything quite good.Are there different types of developers? I think two types by analogy with running can be distinguished: sprinters and stayers.

Sprinters	Stayers	Do everything quickly, don’t think of support	Do everything slowly, support is important	Write cool, incomprehensible for others code	Write simple and understandable code	Jump from project to project	Work at one project for a long time

Distance in development is a duration of release. But is it good to run a marathon? To all appearances, it can be quite life-threatening. There are not so many sports in the world, in which people die haven’t reached 30 km/h speed. Marathon isn’t good for your health and can cause plenty of side effects, including arthritis, tendonitis, heart problems, loss of bone density, etc.So marathon is dangerous, but what about sprint? There are no prizes for guessing that everything isn’t that cheerful with it either. It’s quite easy to get a strain running a sprint, and heart stress is quite severe. Still it’s safer to run sprints than marathons. As usual, middle distance race with average speed looks like the golden mean. Parallels with development can be easily drawn. If it takes long to release then it’s a marathon. If you release every hour – it’s a sprint, if every few weeks – it’s a middle distance race. Our goal is to get rid of long releases. The distance should be divided into quite small releases. If we begin a new product, it makes sense to move in quite long releases, of approx few months. The closer we are to the final version, more often we should release, collect feedback and make fixes. #### Speed

People run quite slowly. Some well-known figures can run at the rate of 38 km/h, but not for a long time. Other well-known figures can run at the rate of 20 km/h for two hours. And some of them can run for 24 hours at the rate of 12 km/h. People are notable for an exceptional staying power and can exhaust an antelope after four hours of continuous pursuit. We can’t run very fast at the long distance. But what happens if we try to? And now a five-kilometer dash is beginning. The famous sprinter George Blocker is leading the dash. He is running all alone. He’s overcoming the first race rounds with an incredible breakaway and increasing the speed he thinks that the finish is near. But he is surprised to find out that finish is 4 kilometers away and his organism is refusing to run any farther. The organism is astonished that it has managed to run a kilometer at such fast pace. George is jogging now, getting his breath and muscles. The peloton is catching up with George at the third kilometer of the dash, the last runner friendly taps him on the shoulder and easily presses forward. And now let’s consider programmers team. It’s quietly working on the release when the project manager comes and says: “Guys, we should work faster! We have an important deadline!” The team replies: “Ok then” and speeds up. In a few months it is obvious that they are missing the deadline. The project manager gives an encouraging speech after which the team works on Sundays, spends the nights at the office, eats pizza washing it down with Burn and works with an incredible speed. But one day comes the fuck it point. The manager is really lucky if the fuck it point comes after the deadline. Having reached this point the team woks slowly and reluctantly fixes the bugs, and does everything not to work. > Staying power is necessary to run faster for a long time.

But how is this power trained in running? Interval training is one of the good approaches #### Interval training

It’s quite simple. A person runs changing the speed. At first we run with an average speed, and then we increase it, then slow down again and speed up again. The interval training improves staying power and increases the speed. Can anything of the kind be applied to software development? Of course, yes. And we’ll name it an interval development. Let’s imagine a small development team which is making quite an important feature of the product. Stage 1. Average rate (2 months)The team begins to work at a usual rate. Having worked this way for several months the team switches to the speeded up rateStage 2. Speed up rate (1 month)The main goal of the stage is focusing. - The team drops all the meetings that are not dedicated to the feature; everyday standup meetings, status reports and other meetings. You can live without them for two months. You really can. - All messengers are switched off for the time working: Skype, ICQ (really?), IRC etc. If there are some dislocated workers, you can leave a channel for them only. You can spare some time to check up your e-mail and messages, but all of that should be minimized anyway. - If your people are usually drawn away by other teams, ask them to wait for a month. They will find someone else. Hang the “Do not disturb” board and don’t respond to any pleas for help - Try the pair programming. When you are sitting with another person, you won’t distract a lot. This way the focus will be kept. - No overtimes!

You can try anything but your main goal is to concentrate on the feature. Away with multitasking! Away with all routine tasks! You will enjoy the result in a few weeks. It’s really great to go home feeling the progress and the scope of performed work. The fourth week is our power lap. The last gasp before the feature release to production. And that’s where you can speed up a bit more and work on Saturday. Finish everything and release it. The real artists do release; Stage 3. Relaxation week (1 week)About a month later the primary enthusiasm fades away and you have no strengths to move on at the same rate. And that’s when relaxation week is needed. During this time you can relax, be late for work, frig around and talk about something interesting. Had a rest? Now it’s high time to work on a new feature. Such working hours have several theoretical advantages: 1. Routine feeling fades away. The work becomes multifarious. 2. The general development speed will increase 3. Speedup mode will increase the team productivity, which will have a favorable effect on the psychological climate of the team.

Fartlek

There’s also an unstructured training besides interval one. Fartlek was invented in Sweden for trail running trainings. Everything is quite simple with Fartlek:Three stages can be distinguished in it: warming up (running at a very low rate), fast run and speed run. What if we’ll apply it to development?The stages differ a bit from those of interval training. Stage 1. Slow (1 month)Unhurriedly create feature UX, lazily write prototypes, examine architecture decisions, think, read and discuss all of this at tea. This stage goal is to understand what we are doing here and how we can do it better. Stage 2. Moderate (2 weeks)Start the development at a usual rate, having tried to slow down minor activities. Stage 3. Speedup (2 weeks)It’s like in the interval development you need to focus, isolate from the outer world and push on. Then we alternate 2 and 3 stages several times. And then get a ready feature. There’s a different mix of intervals and I have no idea which one works better. I guess it’s quite individual. Some teams need frequent rate changes, other feel comfortable to work at the rapid rate for a month. You need to consider the context and try. #### Traumas

Running is a very traumatic sport. The most typical traumas include plantar fasciitis, heel tendon inflammation, strains, heart problems and breast ptosis. Developers also get traumas. The logic string will be the following:Bugs and couch-potato lifestyle → Emotional burnout → Coffee and cookies →#despair.Our goal is to diminish traumas. Let’s go deep into running. Most people run in trainers and land on the heel. According to many researches it’s not really good for your health. Running on the heel leads to traumas of knees and thigh muscles.So what’s to be done? “Maybe we should run barefoot as our ancestors used to do?” people thought, and barefoot running appeared. It seems that many problems are being solved. The step is getting shorter and there’s no such weight bearing. It hurts to land on the heel barefoot, so you have to land on the toe. It seems to be great! But oops! It turned out that barefoot running increases the possibility of heel, shank and jones traumas, let alone callosities. Having got rid of one problem, we faced another one. Then trainers, which were to solve all the problems, were invented. Here they are:But no. Callosities and feet mechanical damages have been eliminated but other traumas remained as they are caused by running technique, not by trainers. It also turned out that heel running is good for some people and toe running is good for other ones. So it’s extremely individual.Does it ring a bell?Let’s draw an analogy with development.

Running	Development	Trainers are safety cushions between the leg and the ground	Testers are safety cushions between developers and clients	Barefoot running	Features release without testers	Running technique change, solving some problems, other problems increase	Development style change, solving some problems, but increase of other pr	Running in funny trainers	Features release without testers, but with automated tests

Really, most programmers don’t like testing. “Leave it to testers, why should we bother?” they say reasonably. It often leads to devil-my-care attitude. “Everything’s ready so now I’ll give it to testers, let them find bugs. I don’t feel like running positive scripts.” As a result the feature goes from testers to developers until all bugs are fixed. It lengthens development time and slows it down (by the way running on the toe is % faster than on the heel). What if we remove all testers from the project? It wouldn’t add to their confidence. They will have to be extremely careful with the functional and run different scripts; they will have to think of consequences. So developers will have to run slowly, on the toe. Automated tests can be written. It will add to the confidence, but wouldn’t let you relax. Which technique suits your team? I have no idea. It’s an individual solution and you should try different things. #### Summary

Let’s sum it up. We have drawn four analogies between running and development:1. Direction — choice of the right features 2. Distance shortening — small releases and features 3. Speedup and staying power increase — interval development 4. Trauma decrease — choice of right techniques

Analogies are really interesting. Consider some knowledge area and find out the way it can be connected with development. You will certainly have new ideas. Whether they are good or not – you’ll find out in practice only. But I guarantee that you’ll be intellectually excited and enjoy the process. Analogies burst is the high-road to innovations.