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?




Comments (6)
  1. Travis Owens says:

    Oh that’s easy… 42

    Now what was the question?

    Ok seriously, I feel there is no silvery bullet here. I just recently started at a company where I adopted many (poorly made) solutions and our team takes their own niche in this mix of poorly designed Access solutions, classic ASP webpages, VB6, broken SQL Server DTS packages, etc etc.

    I think choice #2 is really the only way to go, as taking 1 hr randomly isn’t feasable and actually you have no way to know if a feature will take 15mins or 4hrs until you get into it. I think between every project you should take a day or so and get to any smaller items that have been building up.

    If you work in an enviroment where you don’t have the item to deal with smaller items, you need to push back to middle (or upper if you lack middle) management that you don’t have time for "wish list" items along with daily/new work.

    The more I work with a team of developers the more I realize the worst part of this whole thing is the whole concept of timelines. I think any programmer can attest that deadlines are entirely relative and with each project being relative within itself, pushes all future projects to an undeterimable future date. I really hate being asked how long it will take to make X (although I hope to get better with exp) and I totally refuse to give any deadline for anything farther out that the current project I’m working on. I all to often shoot myself in the foot if give some arbitrary date to the 2nd+ project in the work queue as it’s too easy to get sidetracked to make the date.

  2. MSDN Archive says:

    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 🙂


  3. zzz says:

    Yeah I guess there’s no magic bullet. What about using the #1 approach couple times to plan ahead for the #2 (which would be like like 1 or 2 days the weeks following #1). I am not sure how’d you plan, perhaps try see if there’s common areas for the small things, grabbing atleast those you have a vague idea that the problem could be sitting on the same files/projects and then when at phase #2 work only on that set of problems.. I don’t know 🙂

  4. Scott says:

    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.


  5. Travis Owens says:

    While I haven’t had to work in an enviroment where people are split into "maintenance" and "new developement" roles I can say I totally hate the sound of it.

    There’s no arguing the fact that doing "maintenance" is being the underdog not ot mention it’s a waste of man hours for another team to inherit code from other developers. Plus how do you draw a line between what’s new code and what’s become old (after final deployement all code becomes "old").

    Plus since the "new dev" people know the current code so well, instead of the people on the maintenance team tracking down a bug AND learn all this code (which could be thousands of lines) they’ll just run over to the "new dev" people and ask, undermining the whole concept.

    My point being… I fully believe in application lifecycle where the same group gets psecs, designs the app, codes it, and maintains it.

    I don’t even see a point, no matter how old the app is, that it’s cost efficient to move the app to a pure maintenance team.

Comments are closed.

Skip to main content