How do you handle poor quality code from a third party contractor in another country?

Question

Let's just say the boss is addicted to the price of poor code, and will keep on outsourcing chunks of greenfield projects to cheap labour, only to get inhouse devs to fix the bugs.

Answer 1

Don't pay them until the quality is sufficient.

We are in the middle of this situation at the moment.

Put the maths on the table. Work out the business case, as in, it's not such a bargain in the long run when you look at money lost by the expensive, on-shore coders being paid to fix the problem in the "cheap" code.

Not to mention the friction created by developing requirements and specs to communicate your design intentions to off-shore people.

Answer 2

Try and get the same team of cheap labour coders each time and spend some time establishing a shared-knowledge of what constitutes good code. Make demands to have them meet your standarts.

Answer 3

Get a new job.

Sorry, wasn't trying to be snarky. I made that suggestion based off of this piece of evidence: "boss is addicted to the price of poor code".

Answer 4

I would take the approach that it will cost less in man/hours and possibly money to do it right in house once. Perhaps you can use numbers to back that up, assuming you know how much the outsourcing is costing and how much you and the other devs are being paid.

Answer 5

This sounds like more an issue with your boss than with contractors in another country. Focus on it from that angle. Data about the effort it takes you to fix these things vs. how much it would cost to implement it in house would be helpful here. Also, be prepared to go over his/her head.

Answer 6

Put a price on the time you spend fixing the bad code vs writing it directly.
Don't forget the cost of QA, client support, or angry customers....
Cheap short term can be long term loss.

Answer 7

Define acceptance tests, maybe? Or get the "cheap" coders to implement unit tests? Don't know whether they'd do any better at that than at the actual code, though. From prior experience, very explicit requirements documents can be very helpful. Who's sending out the requirements, and are they a good writer?

Answer 8

Go to the development centre of this contractor, get the team together, explain to the what your expectations are, establish good relationship with the smartest, try to persuade their management to offload the dumbest to other teams.

Write some good code quality standards and accept the code only when the standards are met. You will be in much better position to talk to your boss if you have documents in your one hand and figures in the other.

To this purpose you could make the contractor to commit the code in your repository and have a continuous integration system run on it with all the code quality checking tools running in the NAnt build. Again, do not accept the code with the metrics lower than in agreed KPIs

Answer 9

Create a wrappers on the third party modules and display a big fat error message when something there goes wrong. Then submit several bugs in your bug tracking system pointing the problem with screenshot of the error message each time an error occur in the poor modules. Send the bug reports to your boss and he/she will be convinced to stop using the bad module or will force the outsorcing team to take precautions for the next revision.

Answer 10

Bosses tend to be number crunchers. If you can prove that it's costing them time, money, quality (to the end user/customer) and morale of the developers (yes, some bosses will see morale as currency too!) then you will have a very convincing argument for change. You can spend that money in OT pay to your developers to get the work done in-house and in-standards. You could use that money to hire an internal lower-skilled resource that you could train up to replace the cheap 3rd party developers and you'd only be helping yourself.

If all that fails, then at least you've got an answer for the interviewer at your next job when they ask you why you left.

I'm speaking from experience here. At my last company we used offshore developers who were fairly skilled for the rates we were paying them. However, we were also spending hours educating them, fixing their errors, working around their code and that meant that we were most definitely not benefiting from their lower rates. The overhead of managing those resources ended up being more than what it would have taken to do the job in house which would have resulted in a better, "more-cohesive" result. So, the payoff after months of trying to make various offshoring partnerships work was that our offshore developers were paid to be trained by higher salaried developers and our company went bankrupt. Offshoring wasn't the only reason we went bankrupt, but it did much more harm than good.

I hope my experience isn't typical, as I'm sure that offshore development with the same shop over time would eventually become mutually beneficial, but you have to have extremely deep pockets up front to cover initial losses.

Answer 11

Most bosses like metrics. Document how many hours the inhouse devs spend fixing those bugs. Multiply by inhouse rate. Add outsource rate. Show your boss the real cost.

Answer 12

First of all, I don't think that this is a problem that is specific to having work done offshore. Most developers like to write code and not read it. So, it really doesn't depend where the work is done, if you have a team of developers that inherits a chuck of code from another team. It is very likely that the receiving team will declare that the code is crap.

If the product is of dubious quality and it has a lot of externally visible defects, then it is different.

I think that a good way to avoid this is to make the team that wrote the code responsible to fix it. At their expense, under warranty. Outsourcing firms that provide time & material programming services usually don't offer that. Outsourcing firms that provide a good warranty might provide a better service and charge a price that is much closer to what it should really cost. Otherwise they won't stay in business too long. This will bring the in-house programming team back into play and it becomes a more reasonable business decision as to who does the work.

Negotiating an outsourcing contract with a warranty is a lot harder than just throwing money over the wall for man-hours. But this is something that a manager might understand. Everything else they buy for the company has some sort of warranty. Why not the software?

Answer 13

Timezones can really kill outsourcing. There's nothing quite like a +16hr time difference to drag out a project. Simple problems take can weeks at one 30 minute phone conference per day... especially considering they're going to go home after the phone conference and probably forget 1/2 of it.

Outsourcing works as long as you can specify in great detail the specifications up front. Many problems are not easily understood at that point, let alone perfectly enumerated into lots of component parts for implementation.

Fast iteration is a powerful development process very poorly suited to timezone deltas.

He'll just have to get burned a few times to learn. I've tried to argue this before and it just sounds self-serving.

Answer 14

I think the main thing is that you do not ever fix their code for them. They are not going to learn how to do things right if you keep fixing their stuff. Just send it back to them with a bunch of clear bug reports.

If your code needs to call interface with their code then be very paranoid. Use design by contract pre-conditions with all your code and invest in a good logging infrastructure to capture these kinds of failures.

I found that outsourced work is often so bad that you sometimes need to do your own version just so that you can test what you are supposed to be doing with some reliable code.

When the shit hits the fan in the end you may propose to use that code instead of the outsourced code.

You will actually see similar issues on-shore if junior developers are given tasks that they are not quite up to yet just because the experienced developers are all busy dealing with complex customer issues.

Answer 15

Insource. :) Hire LOCALLY. Support your local tax-base by hiring local programmers and paying them to do the work that has been taken away from them via outsourcing in the past several years. They're going to go out and spend their pay on the local economy. The local economy is going to get the tax revenues. Not only is it good for the local economy, its good for the State and Federal economy as well. Outsourcing has been a cancer and its time for a turnaround.

Answer 16

The only real difference in dealing with the" third party contractor in another country" should be timezone differences. Language and culture are sometimes cited as problems but these type of issues can happen with any contractor.

If the code is poor quality you need to be able to define why and deal with it.

Good luck... as it sounds likely you found out too late.

---

I have had some experience of the "another country" scenario and the problems tended to come down to

• woefully inadequate requirements
• desire to please... so contractor doesn't ask questions
• no acceptance tests
• poorly defined deliverables
• no sharing of bug reports
• one-shot delivery, so no early visibility of problems

Other favourites are of course

• no management consultation in the contracting decision
• loss of local knowledge and motivation due to contracting / outsourcing / off-shoring / downsizing