From a development standpoint, nobody really likes to work on maintenance.  It's more fun to work on the cool new Web 2.0 stuff than it is to drudge through old code following logic that may not be so logical.  It's definately more fun to create than it is fix.  That being said however, it is inevitable that applications will need changes as the business evolves and grows.  So, from a management standpoint, I had struggled for a while figuring out how to keep up on maintenance while also dedicating a majority of our time to new development.

My first attempt at this was a "Friday Folder."  Throughout the week, any requests that came in that I felt confident could be completed within one day would get put into a manilla folder.  Typically these came to me via emailed or printed screenshots with some notes scribbled on them: "change this to display xyz instead of pdq."  I'd collect all of these requests throughout the week and then would hand them to the developers on Friday.  The developers liked it better since they all got to work on project work for nearly the entire week and could then do a bunch of "no brainer" work on Friday.  I would usually give a developer a "friday item" for whatever project he was most familiar with.  So, if I had someone was really familiar with an old application, that developer would get any Friday Items for that project.  This system seemed to work well for a little while and did help to bring some structure to our maintenance requests.  However, there were a few flaws with the system.

One obvious trouble spot with this system is that it didn't work well when a Friday request took longer than 1 day.  Sometimes our Friday requests would carry over into the next week and could even become a week's worth of work.  That disrupted our regular project work and became irritating to the development team.  A second problem was that all the knowledge for each project tended to stay with the developer who knew the most about it.  From a corporate standpoint, this wasn't good.  Though this system typically allowed for each request to get completed quickly, it didn't allow any other developer to gain the necessary experience required for him to maintain the application.  Another problem with this "friday item" system was the business people had to wait until Friday for any work to get done.  The only exception I allowed was if something was broken and needed to be fixed immediately.  So, seeing all of these flaws I began to look for a different way to handle our maintenance requests.  What I have settled on at this point seems to be working nicely.

Today we handle maintenance requests with a "fire fighter" role.  One developer per week is the "fire fighter."  They take all the web help calls, answer all the emails, and work on clearing out our "fire fighter" work item queue.  These work items can now be several days long and, if necessary, can actually span weeks.  However, I tend to like to keep the requests to about 16 hours of work.  Anything too far outside of this needs to go down a more official change request process and get prioritized by The Business.  With nine developers on the team, each developer gets 2 full months of uninterrupted project work in exchange for one week of maintenance work.  This system works really well and addresses most of the problems of our "friday item" system.  The developers actually look forward to their fire fighter weeks (at least more so than the friday items) because they see it as a nice break from their project.  To incentivize that further, the fire fighter developer can work on anything he wants as soon as the work queue is empty.  If he wants to work on building a coffee robot, go right ahead!  Finally, the Business gets to have their requests completed quickly -- usually within the same week of the request.  And every developer has an equal opportunity to work on applications with which they may not be familiar. 

So, after a lot of trial and error, this is how we handle maintenance requests at Rapidparts.  I'm curious to know how others handle these type of requests and if there are systems out there that work better.