views:

379

answers:

7

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?

+7  A: 

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.

RSolberg
Solid point, hard to contest. One could argue that prior defects are allowed to hurt your current progress so you'll learn from them. "If you would have done your previous project properly you would be more successful on this one."The task switching thing -is- a nightmare.. is it too much of a nightmare, pondering :-)
Tungano
The time lost is bad, but the defects you create as a result of imperfect context switching have an impact that is far worse.
Dave
@Dave: that is something that comes from Multi-Tasking in general...
RSolberg
Picking this one as my answer cause it's the strongest argument challenging my current position. My work place has some measures in place to try and remove some of the context switching, I regard them as inefficient from the maintenance perspective. Researching this further, thanks :-) Nice term "trashing" :-)
Tungano
+2  A: 

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.

Pwninstein
I am afraid this is a common line of thinking. Problem I have with it is development sprinting with a bucket of water, loosing half of it along the way. Spilled water being swept up by maintenance engineers, for whom the customer is forced to pay -again-.
Tungano
I can totally understand that - I'm not saying I subscribe to this line of thinking, just trying to provide a possible reason.
Pwninstein
I was asking for reasoning, not what you think is best. Thanks for your answer :-)
Tungano
No problem :)
Pwninstein
+1  A: 

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.

Larry Watanabe
Good point. I think support personnel is just as much a 'user' of the system as the obvious ones. Perhaps it should be a role on the team, the person mapping out functional holes and flaws in the system, figuring out design flaws and such.
Tungano
+3  A: 

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.

David in Dakota
So then the only team you have in-house is maintenance team, interesting perspective.
Tungano
I think this probably happens a lot in a lot of shops. But what people don't talk about is how crappy the consultant-delivered software is, and the additional irony that the consultant was paid better than the people that end up fixing the app.
Bernard Dy
You're onto something Mr. Dy but to be as optimistic about consultants as possible: their goals are very short term (get in, bill fixed # hours, get out) and getting to "done" might have opposing interests to people who have to see something work over the longer term under varying conditions. Having been a consultant myself, I can see how there's pressure to cut corners to be "done" in the shortest time possible.
David in Dakota
+3  A: 

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.

Klaim
I recognize this situation yes. What you describe is more of a specialization... handling codebases that are void of prior knowledge. One could argue that the original team should be able to continue their legacy, even when people are leaving...
Tungano
+6  A: 

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.

Zaki
Very good reason from a product development perspective!
Tungano
+1  A: 

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.]

ChrisW
Code is not well written if it has defects. My only 'subtitle' was that a defect holds value for only one person, the person creating it. Lessons learned from failure? If some maintenance fixes it, the problem may be gone for the user/client but the person from where it originates will repeat it?
Tungano
One of the reasons for "maintenance" might be *new requirements*, regardless of whether the code is well-written.
ChrisW
Sorry my perspective on maintenance was somewhat focused on defects. I was assuming new requirements are something the 'development' team picks up. Of course maintenance has to deal with functional deficiencies also (removing peeps from bulk mail lists cause your customer doesn't know SQL), not always fault of programmers.
Tungano
In my scenario the "software *development* engineers" were off developing *new products* -- whereas as a newly-hired "software *maintenance* engineer" I was implementing really minor new things in an existing product (presumably as part of some customer support agreement). We (the two sets of developers) were now working on different products (for different product managers). I was maintaining software which had already been released, had passed the customer's acceptance testing, and was in the field being used on the live network.
ChrisW