New and Shiny versus Old and Boring (posted by Avi)

I'll take a [very slight] segue from support costs to talk about one aspect of running this web team which I find difficult... How do you strike a balance between working on new projects and maintaining the older ones?

 

We have lots of older applications that are in constant use and have a large amount of feature requests. When those features are urgent we usually get to them immediately. However, the vast majority really aren't urgent - they are nice-to-haves, wish-lists, or corner cases... But they pile up.

 

Now, many of these are trivial, so it seems like we could just quickly fix them and move on. But any coder will tell you that context switching can be very detrimental to performance, especially when you're "in the zone", so to speak. So what do you do? Ignore these little requests, and you'll soon be left with hundreds of feature requests in your queue. Pay them too much attention, your new projects grind to a halt and you end up missing all your deadlines.

 

We're tried three approaches:

1. Spend 1hr of each day (for example) working on small items.
2. Take a few days/weeks after each project to clean up the small items.
3. Attempt the above two, generally fail, and end up having a large queue of small items anyway.

We seem to be pretty good at #3, but the first two are not as simple as they seem. #1 assumes that you can split your day into periods of calmness - spend an hour here, seven hours there. The truth is that often throughout the day you're being pulled in different directions, and it's often impossible to set aside periods of time. #2 ignores the fact that it's difficult to put aside new projects (which are usually high priority) for a few weeks. How do you justify to customers that you're going to spend a month dealing with tiny issues that don't have much payback?

 

At this point, I'd give some brilliant solution to this problem. It would be simple, practical, fool proof. You'd be amazed! ...Unfortunately, I've got nothing :)

 

What about you? Any ideas?

 

Avi

Comments

• Anonymous
  June 01, 2005
  The comment has been removed
• Anonymous
  June 01, 2005
  I think you're pretty much spot-on Travis.
  
  You bring up an interesting point about timelines and estimates. Software engineering is notorious for being different from "real" engineering disciplines in being unable to accurately predict schedules.
  
  I took a class back at uni about strict software engineering and schedules - and I was shocked at how accurately I managed to predict the time/space/bugs a program would cost - but that was while working in a bubble.
  
  This is so different from what we're doing because we are far from a stable environment. I'm imagining that an engineer overseeing the construction of a bridge doesn't get called up every hour to add some extra bricks to the old bridge he recently built :)
  
  Avi
• Anonymous
  June 01, 2005
  The comment has been removed
• Anonymous
  June 02, 2005
  I think this is a very common problem to have. The best solution I've seen in action so far is to break a product team up into two smaller teams. One team works on the current product (Old and Boring) and the other team works on future features (New and Shiny).
  
  The current product team is always working on the product that was last released by the future features team. Their tasks usually entail making small enhancements and fixing bugs. The future features team's tasks are just that... working on the "big" things for the future product.
  
  Obviously, this is only possible if resources are available for two separate teams so it doesn't always lend itself as a solution.
  
  Scott
• Anonymous
  June 15, 2005
  The comment has been removed
• Anonymous
  June 08, 2009
  PingBack from http://cellulitecreamsite.info/story.php?id=8639