Why separate maintenance work from development work?

Question

I work at a company where maintenance is being done by the same team that brings life to a piece of software.

Very often I hear about organizations that have a separate maintenance team or a maintenance programmer. What I wonder about is -what- the reasoning behind this is?

Apart from ditching 'old code' to lesser mortals, is there any?

The lessons learned from maintaining your own "junk" are of much higher value? Isn't fixing defects far more effective when done by those who caused them to begin with?

Am I missing any real reasons why it might be beneficial to have a separate maintenance team?

Answer 1

The concept that comes to mind to best describe this is "thrashing." This is essentially the switching costs that you have associated with doing both maintenance work and development work. This is probably the biggest reason to separate the responsibilities. Others include allowing junior or entry level programmers the opportunity to get their feet wet, and keep your more experienced developers producing higher value items.

Now at the same time, I think there is some value in a developer that wrote an app having to support it. First, they will very quickly find issues in their code that they can learn from. Second, they will think about maintainability and quality of code since they have to support it.

Real Life Thrashing Example:

You have been assigned a 1500 hour development project and are also responsible for systems maintenance and support for your last 3 applications. During this new project, you are interrupted 7 times per week on average to support these 3 apps. Each time you begin to work on the other 3 apps, you spend 20 minutes getting your mind wrapped around the issue. After fixing the issue, you then spend 20 minutes getting your mind wrapped back around the code you last touched in your new app. This is a total cost of 40 minutes per interruption or 280 minutes per week. This means that you lost 2.67 hours of productivity in the week just on switching over to support these apps.

Answer 2

I have been working on an agile team for well over a year. I think it doesn't really matter in case of a live product (by that i mean clients using the latest versions only). But say you have several versions of your product out in the market and you have to support each one of them.

Take Bentley's Microstation for example. Its a design application for 3d (architecture, plant design, rails roads bridges etc.). Now lets say we have v8, v9, v10 out in the market. They have different features, and file format has changed significantly over versions. But the projects are so huge (or the clients are so important) that you have to support v8 clients and v9 clients while also developing v10 stuff. So it is necessary for the company to have a maintainance team (or time) allotted to previous versions. Also, usually these teams are called Customization teams if your product supports customization and the above mentioned scenario.

Answer 3

The problem is more practical I guess:

• old code have been written by people not anymore in the company or team;
• old code was written by external developers;

It is really common in a lot of company to have a code base that are not anymore maintained by the original coders because they are not there anymore. If the code base is big enough, someone have to keep it up to date so they are called maintainers.

If you can avoid this case, good for you, but be sure that it's always temporary.

Answer 4

I will not say I agree with the practice but in many organizations consultants are brought onboard to write software in short, hurried efforts after which the projects are handed to in-house programmers to "maintain." The rationale is that you can bring in someone who is more skilled without training and then have them include "knowledge transfer" to people who will work on keeping a piece of software intact.

In short, much of the time it is done for political/impractical reasons.

Answer 5

I would think the motivation behind splitting the maintenance and feature development teams is to keep things running smoothly: if the feature development team keeps having to stop what they're doing to handle a bug fix, then the project will stall. Having a separate maintenance team would free up the rest of the developers to keep the project/product in question moving forward.

Answer 6

My first job was maintaining some software modules, whose original developers had moved on to some new project.

I'm guessing:

• Makes the new development more predictable, easier to schedule: because the developers aren't being called off it to fix some unknown-in-advance number of maintainance issues

• Opportunity to train new developers (e.g. me)

Furthermore, the code I was maintaining wasn't "junk" -- it was telco software, an early packet-switched network, which had been deployed to customers like Bell etc. It was well designed, well written, testable (suites of automated test cases), maintainable, plenty of log files, some design documentation ...

... the subtitle to your OP seems to be , "Man, this code stinks! I wish I could get the original developer, and rub his nose it: that would learn him!"

So when the code's well-written already, that argument (teaching the original developers) isn't applicable.

When I say I was doing "maintenance" is was kind of like new feature development but of very minor features ... for example, interop with new customer devices which interpreted the protocol spec in some slightly unusual way.

[I'd analyse and diagnose the problem, and code a fix; and a QA person would add a new corresponding test case to the automated test suite.]

Answer 7

One advantage I can see is that then there is at least one other person in the organization who is responsible for understanding the code well enough to fix it. Also, this person will have a different agenda in mind and can review the code from the perspective of maintenance, if he is brought in on design/development reviews (which he/she should be).

Also, "maintenance" may refer to a host of activities such as deployment, configuration, backup etc. which should definitely be handled by a different team.