codes roads n bikes
Wed, Feb 1, 2006
I got to thinking lately about the amount of projects I’m working on at any one time. It’s calmed down a bit but at one point I was coding for 6 different projects, all at the same time.
Now, that doesn’t sound healthy, especially if you come from an exclusively waterfall model of development, where you work on one project at a time for months or years and you have a big party at the end of it, or not as the case may be.
Where do the roads fit in then? Well, they say that if you build roads, people will use them. Build a bypass and within a certain amount of time the bypass will be just as congested as the through route it replaced. Build ‘em and they’ll use ‘em.
The same is true for software skills. I learned this ages ago. I used to spend days and weeks at a time in kernal debugging with SoftICE and it was a relief to come up and spend some time in user land. During the spare time I had I’d explore the Windows API, the common controls and dialogs and build wee applications that didn’t do much except exercise that API. You know, exploring Zip files and tree views and all that. Pretty useless you’d think. Until a couple of weeks later, those skills would be needed. I’d need an installer for the drivers I was coding and lo and behold, I had a raft of API skills I could use and nice “unit tests” in the form of joke applications to remind me how to use them.
So the same holds true in software skills as in roads. Build ‘em and you’ll use ‘em.
Now to the bikes. Interval training. It’s a very effective way of building your fitness. Go out on a run, 100 miles or so, nothing too much and every now and then, go like the clappers, maximum effort, keep it up for 10⁄15 minutes, then relax back into touring pace. Every so often, do the same, ramp up the effort to max, push yourself to the limit, then relax again. Over time you’ll build up your stamina and fitness. OK, maybe 100 miles is quite a lot to start with. An evening 10 is fine.
How does this translate to coding though? Well, some people thrive on the variety of multi-project development and we rarely take on projects that are as different as chalk and cheese. So what we end up with is a portfolio of funded projects that are synergistic and exercise all our software skills. Spend a week or two on one project, thinking deeply about designs and solutions, doing some coding, some unit tests. Software interval training. Take a break, catch up on institutional housework, clear helpdesk calls. Then move on to the next project, taking the skills you built up in the previous intense interval to enlighten your decisions on the current project. Decisions that will build up to more interval training on the next project.
Multi-project development exposes you to many different problems that users encounter in the real world and these experiences feed back into your institutional knowledge. Your advice giving capabilities increase. If one of those projects is a large institutional one on a critical path, you’re in a position to draw on vast stores of skills and experiences to inform your decisions on that project to chart a path through to release.
Projects will also stall for all sorts of reasons outwith your control. Politics, dosh, hardware but you use the time to build some more skills, which you’ll use, guaranteed. You’re also keeping abreast of the latest developments in the area in which your projects operate. You’re spread within a discipline. Not to extremes. Just enough keep you interested and your brain ticking over and to be a useful oracle of knowledge to your institution.
So although multi-projects are probably not the norm, some people thrive on the challenges of real-time management, iterative development and extreme programming pratices. To say nothing of the constant building of knowledge and skills, which you know will be used in future projects.
So if you’re one of those people and you think you’re overworked and undervalued. Sod it.
Start laying the tarmac and get out on that bike!