Blog

Every once in a while every software engineer finds themselves bouncing between several projects in a short amount of time.  Sometimes it can’t be avoided due to resource or time constraints.  Perhaps there is a code freeze looming or there aren’t enough developers to go around.  But all too often it is simply the result of poor planning or prioritization.  Switching between projects on a relatively frequent basis can have a negative effect on the development process.  Not only is it incredibly aggravating to the developer, but it also costs money…

The cost comes in the form of what I like to refer to as the ramp up and ramp down time.  To put it simply, five “one hour” tasks in different projects can easily take six or seven hours to complete.  This is because time is spent checking out repositories, loading the applications in IDEs, starting application servers, etc.  Then there is the time taken to get your brain back on track with the new project Maybe Project A uses Java, struts and kodo, while Project B uses Java, Spring and Hibernate, and Project C uses Apex, etc… Switching your perspective between frameworks, JDO implementations, and programming languages takes a few minutes.  Individually, we are only talking about a couple of minutes here and there.  But it starts to add up, especially when you are switching often in a day.

To make matters worse, this transition time often lies outside estimates, so the end result is going over initial estimates.  Remember the five one hour tasks that took seven hours?  Who pays for those two extra hours?

Let’s use an analogy.  Assume you are driving from West Fargo to the Twin Cities, a distance of about 245 miles.  At an average speed of 70 mph, a reasonable estimate is that should be a 3.5 hour trip.  But what happens if you have to get off the interstate every 50 miles so one of your kids (God bless them) can use the bathroom?  Or you need to stop for gas? Or getting food? It might only take you 15 minutes to make a stop, but if you have to do it four or five times over the course of the trip, you are going to tack on an extra hour to the trip.

The solution is to minimize the amount of times you have to ramp up and ramp down.  In my trip example, few people would make that many stops in a single short trip.  More than likely they would do bathroom breaks, gas, and food all in one stop.  Much faster.  The same works for development.  Given the same five tasks, if task 1 and task 3 and both in the same project, do them both first, even if task 2 has a higher priority than task 3.  As much as possible, group tasks in the same project into the same block of work.  This puts the ramp up and ramp down time on the initial task only, reducing time spent on the tasks as a whole.