The projects I design and work on are maturing (at the ripe old age of two years). And so they require some maintenance.

There seems to be two approaches to fixing bugs: random assignment and area ownership. I'm pretty biased toward ownership but I'll try to stay neutral.

Random assignment means that whenever you find a bug in the system it gets assigned to whomever is free. This is good because you don't have a lot of down time and the bug gets assigned quickly and lets the original developer work on whatever they are currently working on. This is bad because frequently the person assigned has no idea how the flux capacitor works and ends up asking the original developer anyway. This seems favored by lots of project managers. Not sure why, I guess it's the idea that all resources are interchangeable or they don't want to have developers taken off new development to do maintenance. I haven't figured this out yet, but please feel free to conject.

I favor the ownership approach where programmer A writes some code and then as long as anything breaks, programmer A fixes it. This is good because programmer A knows the code and can fix it the quickest, but is bad because programmer A is probably busy on something else. This is also bad because programmers don't like to be digging up code they wrote 5 years ago and fixing it. A similar approach is that a team of programmers work on an area and bugs get farmed out to the entire team.

I think the best way to knock out software bugs is sort of a hybrid approach where teams own code and figure out who knows it best and moves them onto the bug temporarily until the bug is fixed. This means that the project plan has to set aside a certain amount of time for maintenance even when developers are working on new code. This should fix the problem of programmers spending 8 hours fixing the legendary "5 minute bug" (I'll post about this some other time- I had a CEO who constantly had these "5 minute fixes" that he wanted).