Take the 2-minute tour ×

What is the typical arrangement for the maintenance of applications that are not developed in-house?

Note: by maintenance, I mean bug fixes, optimizations, small modifications and future extensions.

share|improve this question
I'm tempted to answer "nobody, because the code will be discarded and rewritten"... –  user281377 Jan 6 '11 at 9:54
add comment

4 Answers

up vote 6 down vote accepted

This is one of the unspoken (well, unspoken at management level) problems.

Scenario 1 is that maintenance, support and enhancements are done by the off-site company. This presumes that they still exist in 5 years time (there's a risk to the business there). The costs involved in this ongoing care should be factored in at the start.

Scenario 2 is that the work is "dumped" on the on-site IT department. From experience, it's often not well received, especially if redundanices have been made based on the decisions to go off-shore. Even if it is well received, you have the learning curve of trying to understand someone elses code. If you get time to look at the code at all before go-live, you've been very lucky! It's usually all fire-fighting stuff. It's also frustrating when your manager can't understand why it takes you X times longer to do something, just because 90% of your time was in understanding.

Apologies if this comes across as overly for or against off-shoring. I believe that to be strictly off-topic, and tried to temper my response accordingly! ;)

share|improve this answer
add comment

That needs to be considered when the project starts but there is no fixed answer, it will vary from company to company and project to project.

If there is an in-house team it can be handed over to them to support and enhance on an on-going basis. Obviously the issues with this are the issues with any handover to people who weren't involved from the outset.

If you are going down this route then I'd recommend having members of the internal team involved from early in the project, carrying out specification and code reviews and so on, so when the handover comes they understand what they're looking at. UAT is a good time to bring them on-board in a hands-on capacity as they could get involved in some of the bug fixing as an easy way in while support is still available.

You need to make sure that the handover is included in the contract and is correctly resourced on both sides and that the final payments to the outsource company are dependent upon it being completed to your satisfaction.

Alternatively the company who completed the project will likely be happy to support it on an on-going basis (for a fee). The issue here, other than the cost, is that you won't usually get continuity of staff, certainly not long term, and the handover is outside your control so you can't even make sure it's well managed.

I've seen this happen (from both sides of the fence) and what you often end up with is a poor handover from the original developers to the support guys which is then reflect not only in lower code and product quality, but also in the cost of enhancements back to you (as the estimates from the new developer are higher because he doesn't really understand the system and in effect you're paying for him to learn, despite the fact you paid for that company to write it).

Personally I'd always go the internal route for support (I've seen third parties lose source code and I think these things are too important to trust them with), though I understand that's a strategic decision and if no team exists it's potentially a hard sell.

share|improve this answer
+1 for having a life-cycle plan when the project starts. These things have to be thought through very carefully and allowances need to made in advance for maintenance. –  Angelo Oct 10 '11 at 13:03
add comment

Usually some amount of maintenance is included to the contract (with a dedicated price or as part of the project), and consequent updates go at a cost.

share|improve this answer
add comment

Generally, a new deal can be made in these two forms for maintenance:

  • A maintenance plan for certain ammount a month (if work is somewhat sporadic).
  • An hourly rate for maintenance work.

For new features/optimizations/extensions:

  • Negotiate several packed together as a new project (iteration).
  • Negotiate an hourly rate (and give an estimate if possible, making clear it is an estimate).

Personally and as a developer, I like to handle everything as a project, and bugs, I fix them for free. Small optimizations/modifications, if they take me less than half an hour, I also give them for free (that keeps my customer happy), if not, I charge by the hour.

The ideal situation would be if your client has an IT department, then you can provide them with the necessary technical documentation so they can take charge of the maintenance while you continue adding new features.

share|improve this answer
add comment

Your Answer


