Maintenance teams vs. not-so-focused development teams

Question

My organization is doing a lot of new development using Scrum, while maintaining a lot of old code. While we try to keep each development team focused on the task at hand, it is difficult because many team members "own" a piece of historic code that needs to be maintained.

Some organizations solve this problem with a separate maintenance department, but I don't think that sounds right, because nobody wants to be a maintenance programmer, and the developers need to be confronted with their own less-than-perfect judgements.

How do other organizations solve this problem? How can a company be productive at all beyond the startup phase?

Answer 1

We have a similar challenge right now. I believe you're right to keep maintenance work located with the code owner, for reasons of responsibility (reducing moral hazard). Here are the ways we're attempting to confront/solve it:

1. Allocate time for refactoring and redesign to minimise the longer-term burden of support work
2. Develop the products in new directions which will generate more revenue - and which give us the opportunity to merge maintenance work into new development work
3. Ensure the maintenance service is sufficiently compensated by clients to make it worth spending time on (this may not apply if you're an internal team rather than a consultancy)
4. Make sure everyone has enough new stuff to keep them interested

All these approaches together make it workable. But as I think I heard someone say once, there's no silver bullet.

Perhaps the best single thing you can do is to try to remove the distinction between maintenance and new development. Every action of a software developer starts with some existing body of technology, and ends up with a better one. "Better" can mean more powerful, new features, better designed, one less bug - whatever.

Sometimes the existing body of technology is your IDE and the standard Java APIs, and "better" means that you end up with a new CRM application. Sometimes the existing technology is an intricate corporate application and "better" means that the payroll run works accurately without manual checks.

As long as "better" brings benefits to enough people to pay for the effort it took to get there, you have a sustainable process.

Answer 2

There are people who want to be maintainance developers.

On the other hand if your key resources are tied up supporting old application it's very difficult for them to do anything new especially if the quality of the old code is not excellent so they have spend significant amount of time on it (don't know if it is your case).

More importantly if a certain person has ownership/responsibility over certain code it spells trouble if he leaves or is on holiday and you have a problem which has to be resolved.

To resolve this you could create a Wiki (KM), re-factor and comment the code, add unit testing and/or automated regression testing. Then make sure that people do not own anything anymore and encourage people spending time on other team members code, learning it and working with it.

My answer to a question of about the maintainance teams: http://stackoverflow.com/questions/207925/how-to-keep-business-support-team-motivated#207979

Answer 3

I think one of the principles of agile development is that the team owns the code rather than an individual. The incentive for not writing bad code isn't that you have to clean up your own mess, but accountability to the team.

The time to be confronted with less than perfect judgements is in a code review with other team members, not when there is a production bug.

Answer 4

If certain apps "belong" to a single programmer or a single team (and they should belong to teams, not individuals) then you just need to make any updates to those projects part of that team's backlog.

If there's a problem with a legacy app then that work gets added along with the appropriate acceptance criteria to the team's backlog. Then in the next sprint planning they can accept that "story" into the sprint backlog according to the business's priorities.

Answer 5

Sounds to me like a management problem. No one should "own" the code. It belongs to the company/team.

As for being a maintenance programmer, I'd love to be one; as long as I actually got to do maintenance and not 'enhancements'. To me, maintenance means that I'm going to do things that are going to make the program better: refactoring, re-imagining, bug-fixing. In my experience, though, most 'maintenance' is really just prolonged feature creep. You're expected to continue to add features without ever being allowed to fix or update the code.

Answer 6

While I agree with John Kraft that theoretically nobody should 'own' code, the reality of life is that if Matt wrote the XYZ module then he's most likely the one who can turn around a fix to that module the quickest. I've seldom seen where this wasn't the case. Typically the ramp-up for someone else to become useful on a project is considerably longer than the original developer.

At my shop everyone does new development and everyone does maintenance. We schedule all of this in our iterations and it works well here. I suppose in a large software house it might be more difficult, but here we have excellent communication because of our size and familiarity with most of the stuff we right. We tend to do maintenance on the stuff we originally wrote or we get up to speed if needed to fill the gap.

I don't mind maintenance work myself - it offers opportunities to refactor my old code. :)

Answer 7

There are two approaches... us a sustained engineering team (who just fix bugs) or spread the bugs out across the whole team. Given the choice I'd always do the latter. The pros and cons are outlined here.

Scrum and Supporting Your Existing Products

There may be hidden debt that makes this harder to start with; knowledge silos (only one person can fix a given bug), quality debt (more bugs than you can deal with), general technical debt (poor codebase that makes bugs take longer to fix) and test debt (no automated tests so fixes are hard to test. You need to pay this down. If you let it build up then sure, you'll never do any new product development.