What Pitfalls Exist When Outsourcing Code?

mmmmbeer asks: "I have a question for anyone who has outsourced programming jobs to overseas companies. My company is considering doing this, which in theory will allow us to dump off a bunch of (supposed) 'grunt work' and free up our programmers to do other work. One of our management's reasons why they think this is good is because the contracting company can 'throw a bunch of coders on it' and therefore get it done quickly. To me this seems to violate Brooks's Law. We (the in-house programmers) are also worried that the learning curve will in fact be great enough that, even if the extra manpower works to their (and our) advantage, it could still be done faster and better in-house. My question is, has anyone had any experience with this, good or bad, and do you have any warnings or suggestions for us?"

When they don't have to support it, it'll suck.

After all, their goal is "Get it done as fast as possible and get paid". They don't care that 3 years down the line, some poor schmuck will have to figure out whats going on to be able to add some feature. And even if you gripe, those coders are long gone. Combine that with their learning curve to know enough to do stuff with your learming curve to understand what they send back and you're far worse off than your company doing its own work.

It's no good

The small company I work for tried this a few months ago. We got a grant from the state that was supposed to boost "corporate and academic cooperation" or some crap. My company is in Indianapolis and chose Rose Hullman to outsource a fairly large but not too difficult development project.
It was a complete nightmare. We spent months designing the project, teaching them our somewhat odd database structure, and laying out exactly what they needed to do. That was about 9 months ago and they have provided us with are excuses. Maybe it was because we worked with college kids, but we were paying them a fairly good chunk of change. It's not like we had a major "culture clash", the average age in my department is about 23.
After that, I would say that any project that needs to be done properly and on time, should be done in house.

-B

Black Boxing

Speaking as someone who has freelanced (i.e. companies outsourced to me), one of the most critical things for any project which is going to be done "off-site" is whether it can be black-boxed.

If the people setting the parameters of the project have a sufficiently clear idea of where the boundaries of the project are, and how it fits in to the other work people are doing, then it's a candidate for outsourcing -- otherwise forget it. The project has to be sufficiently discrete that the developer doesn't have to constantly be in contact to negotiate how their work meshes with anyone else's.

So things like "an application which does the following things" are candidates for outsourcing, while "a solution to the problem we are having" or "add functionality to this thing" or "debug this system" aren't.

Note, I am not saying BlackBoxability is sufficient, merely necessary. If the project cannot be treated by your side as a Black Box, then don't let it out of your site.
----------------------------------------------

The pitfalls of outsourcing

I'm currently in a couple of conversations on Usenet about the use of alternative programming languages (in other words, "other than C") in business. The claim has been made that the use of certain programming languages can improve programmer productivity by two or three times or even more. I find those claims difficult to swallow.

One main reason I find those claims difficult to swallow is the same reason I have difficulty accepting the supposed benefits of outsourcing: The benefits derived in either case are a reduction in the amount of coding effort, but an awful lot of the effort involved in producing programs goes toward understanding the problem and creating an approach to solve the problem efficiently. That effort cannot be affected by any reduction of the coding cost.

For local programmers, much of the process is left unwritten. For example, the last job I did for my first real employer had this as a specification: "Implement submersible pump control on the gas-flow computer", but it is unrealistic to expect overseas programmers to work from a specification that vague. To make the change to the gas-flow computer, I had to spend an awful lot of time talking to people to find out how it needed to be implemented to work with the SCADA systems that the new firmware was intended to work with. Fortunately, all my experts were nearby and I could schedule meetings for all interested parties to discuss the approaches I could take. Once I understood the problem, the coding went fairly quickly.

It doesn't matter how smart those overseas programmers are and how good they are at writing code that matches the specification if the specification is incomplete or inaccurate. That means that the successful outsourcing project will have lots of extra effort spent on the specification. Additionally, it is necessary to work out management procedures that enable the contractee to determine whether or not the deliverables are what they actually want before it's too late, which just about requires control while the coders are doing their coding. That's difficult enough when the programmers are in a different building. It's nearly impossible when they're on a different continent.

Finally, I leave you with this thought: Outsourcing may free the programmers from the need to actually write the program, but that just leaves them with the task of writing all the documentation and we all know how much programmers prefer writing documentation to writing programs, right?

Good Software Engineering

I am a comp. sci. student doing a summer internship at a company that has completely outsourced the development of their next generation product (they needed to do a complete rewrite from scratch). I think most people would think that this would mean job losses for developers, but instead the development team is moving across from supporting the old product, to designing the new product using UML. The development team is actually growing, despite the fact that they are writing less code.

As a comp. sci. student, I study software engineering, and I have to say that they are actually doing a perfect textbook job engineering their new product. We design exact specs for what the code should do. They had this over to another company (actually, overseas), and we demand fully documented and tested code.

We are a little behind schedule, but we are in total control, and we have a perfect measurement of what stage of completion we are at, as we hand them the problem task by task. And this is a Good Thing. It is much better to be a little behind schedule, than to have management force you to rush delevelopment, and produce shoddy code.

Management's hands are tied. They know that we just have to wait for the code to be delivered. The comany we use know that we do all the design and can easily switch development elsewhere, if they do not get the work done in a reasonable amount of time. Yup, our experience with outsourcing devepolment seems to be entirely posative so far.

cheers,
G

Be careful...

One of the companies I had worked for did this on a project, not overseas, but in the US. What we ended up with were
- missed deadlines,
- hacks/cluges instead of well designed code,
- next to no documentation,
- poor support when the inevitable problems arose.

We ended up putting lot's of man-months on fixing the things they gave us that were supposed to work. In the end we'd have done just as well, if not better to have written it all ourselves. I say better not b/c we could have done the job faster, but we most definately would have produced a higher quality product.

Outsourcing Has Worked for Me

Here's how I do it:

I pay a little bit up front and then upon delivery of results and I am somewhat lenient.

I never pay by the time unit (hour/day/week/month, etc.).

I use exclusively use Siberians who have a decent command of technical English and communicate only via email.

I either give them a lot of lee-way in what the are going to do and how they are going to do it and pay up very leniently upon completion, or I nail things down with a test criteria that is complete enough it will require only one or two more iterations to get something I can deliver.

I don't set "deadlines" but rather sliding scales of compensation that decrease dramatically from early delivery to late delivery. At worst, they make only what I paid them up front, which is usually decent by Siberian programmer standards, so they go into the relationship knowing I can't screw them.

Top-down vs. interactive design; special knowledge

It's relatively easy to outsource development of a large project where you've done detailed top-down design work first and didn't make any seriously mistaken assumptions that will require restructuring the whole project later to fix. Some projects work fine in this environment, some don't. It's nearly impossible to outsource tight interactive cycles of "design a piece, prototype, evaluate, redesign", especially if the project requires extensive technical knowledge of fields outside the programming business. Some projects have to fit into this space, some don't, some don't have to but are more efficient if you do them this way. On the other hand, outsourcing a project to someone who's got specialized knowledge when you don't can be a major win.

I used to work on air-traffic control systems; we were using the biggest hairiest Mil-Spec (1067?) design/development methodology that required 175 separate deliverable documents in 3 years, all of them entirely compatible with all the other deliverables that had come before, which was abso-expletive-deleted-lutely impossible to do even if you had all the requirements explicitly laid out up front, as opposed to knowing only that if two airplanes crash it's your fault, so everything's rabidly conservatively overspecified beyond the limits of current technology, plus you don't *know* the limits of current technology because the other subcontractors on the project haven't developed it yet, though they got their requests for extra milliseconds for their components of response time in before your team did, and the real specs of the current system consist of antique mainframes running undocumented JOVIAL code you'll need to be compatible with and operations techs named "Skippy" who know each detail very well, wouldn't know a "big picture" if it bit them on the elbow, and have to have each detail pried out of them one at a time by trial and error. (We found a successful way to work in this environment - it was a design "fly-off" between our team and another team of contractors, both on time&materials, and we *lost*, getting ourselves out of the line of fire while the poor suckers who won *still* haven't finished a decade later, and BTW, we knew back in ~1987 that the specs for the regional system wouldn't let you fly the Concorde across the Continental US above Mach 1 even if you *were* allowed to have sonic booms over populated areas.)

Re:As with everything it depends

In my company, I've churned out crap. I've also been on the cleanup crew for a kludge-fest. And I've managed development of VERY clean systems.

As a guy who manages outsourced projects for companies, I have a few observations:
1) Make sure you have specs nailed before starting the project, -OR- let the development company help you with the specs. If they know their business, hammering out specs should be part of the cost of the project.
2) Listen to them -- if you're hiring them for expertise you lack, don't pretend you know it all. And if you DO know it all, then listen and see if they know it, too.
3) Even when a pro outsourcer is bluffing about his knowledge, odds are good that he can get up to speed on something faster than an average coder. We get paid to absorb languages quickly, and do so regularly. If you practice new languages every other month, and it stretches your brain to be ready for the next one.
4) Be flexible when it doesn't matter. If you don't specify whether to use tables or frames in web pages, don't get upset because they guessed wrong. Or be prepared to pay them to fix it. If you don't specify things, you don't get a vote.
5) Let them know when things REALLY matter. If you have a presentation coming up for Venture Capitalists, don't wait until the day before to mention it... even if that's already a deadline day. Most deadlines are actually a bit flexible (and if your planning doesn't have flex time in it, you're dead anyways) but those that are brick walls need to be flagged EARLY.
6) Quit moving the target! Decide on what you want, let us know, and get out of the way. I have seen budgets triple due to feature creep [everything2.org] and the client blamed us. It isn't a "bug" if you didn't spec 4 decimal places instead of two. We asked, went with your answer, and now you have to pay to change it.
7) You get what you pay for. Everyone rags on college degrees and experience when they're in high school, but you WILL see the difference if you have knowledgeable coders working on your stuff. And knowledgeable managers overseeing the project.
8) Pick your coding house like you would your employees. Ask for sample code, references, interviews, whatever. As many people have said, think of it as a long-term investment.

It's definitely possible to outsource code if you're careful. If you're sloppy, then keep it in house.

Good luck!

International Outsourcing - a Provider's view

Want to outsource overseas? Here's some Do's and Don'ts, based on my own experience as a code provider

1. Make sure the task is well-defined. It should have really complete specifications of all interfaces to the outside world, plus a reasonably good specification of what it should achieve.
2. Have an agreed set of acceptance test procedures. Otherwise how the heck do you know if what's been delivered is acceptable? This doesn't just mean "input dataset A get result set B" but also standards for coding style, commenting, and results of lint or other quality tools.
3. Go with people who have a track record. Before giving a non-trivial task to Freedonian Hackers Inc. , give them a trivial task, and see how they go. You will probably be horrified. If Slobovian Widget Makers have done good work in the past for you, then go with them if you possibly can.
4. Recommended Countries: Russia (But language barrier is a problem), Australia (But coder availability is a problem, many have decamped to the US where wages are tripled and standards lower), and for COBOL (only) some Indian firms. Others are disasters, so test before you buy.

Yes, I know the above is common sense, and any large, professional IT (Information Technology) shop should do this anyway for in-house efforts. The point is that you can get away with not doing a lot of specification, documentation etc when dealing in-house. But externally generated stuff has to be of a much higher quality, simply because you won't have anyone who's familiar with its undocumented features.

When this works, it works well: Because the end-product, as it's well specified, under good Configuration Management, well documented etc is better than the in-house stuff. It costs more hours and resources (but hopefully less money) though.

I've actually seen a genetic-algorithm generated AI system from Australia ported to Europe, and integrated with a multi-million LOC system that worked adequately the first time it hit the target machine. After 1 week of debugging, it worked according to spec with zero category 3+ defects. Passed a 6-month continuous operation test shortly thereafter. Don't expect this to be the norm, but it can be done.

Russian programmers

I learned programming in Russia, there I also met a lot of programmers and now I have a pretty good picture of how they are different from American/Canadian ones.

A lot of programmers are actual geniuses, they all have finished some technical universities, which, by the way, are much much harder than American ones. Emphasis on Maths and Physics, as well as very strong Computer Science theory is practiced a lot.

Russian programmers are very very cheap. For $200/month you can keep a programmer happy. That's pretty unfortunate. Most of those people are real geeks and really enjoy this. But hell they are smart. I have not seen more knowledgable programmers in Northern America.

So, getting back to the topic, if one would consider outsourcing a project to Russia:
* choose one of the big cities (St.-Petersburg, Moscow, Kiev)
* it will be dirt cheap
* if you have real good specs - you'll have your code in no time. Good quality code.
* better have some connections in Russia, otherwise you might have complications.

Good luck. :)

Outstanding results with an Open Source approach

We have been getting outstanding results from our partners in Russia and India.

I think that many of the deals offered by overseas development shops are a bad idea. Some shops will offer to do fixed-price work that is very expensive and time-consuming to specify and test. Others will rent a mass of undifferentiated (and poorly trained) bodies for long-term projects.

We have gotten good results using a very different approach. We make our overseas development partners into an integral part of our development team with daily communications.

Managing one of these projects is like managing an open source development project. The team communicates over the Internet on a daily basis. Code is checked in every day. There is extensive peer review and feedback every day. There are daily builds and stable builds that are shared. There is a stack of bugs and issues.

Most importantly, there is no us and them. Instead, there is one unified team that happens to be geographically distributed. It turns out that a lot of "them" are very talented.

Can you violate Brook's law this way, getting faster results and more features by adding more coders? Sure you can, in the same way that open source projects get huge scalability. You just need to do it at the right stage in the project. I can think of a few simple rules that make this scalability happen:
* Make a good object oriented architecture with defined places to plug in.
* Do the architecture and initial builds with a small pioneering team. This way, when you scale up the development team, the new people are starting with something that works.
* Build every day.
* Make all of the source code and API's available to everyone. That way, people can fix problems and keep going, instead of spending days on workarounds.

I would recommend the following deal structure to get best results:

* Maintain a personal relationship with the management of the development shop. This is easier if you work with a small shop, which I certainly recommend.

* Screen the individuals working on the project using resumes and interviews. Good programmers are much better than bad programmers. Make sure you get the good ones. Many Indian shops will offer a (bad) deal where you get a generic developer (unnamed), and they can substitute less experienced people at will. Do NOT let them get away with this. Select and keep individuals. As always, offering good, interesting work will help you do this.

* Pay for person/weeks, rather than for hours (subject to petty disputes) or for fixed-price deliveries (these are very expensive to specify and test).

* Offer a long-term commitment. This should get you a discount and access to the best engineers. Stable cash flow is very important for software development companies that want to lock in a base of revenue and then grow on top of it. Trade them the steady cash flow for access to the best talent at good rates.

* Make them work for referrals. Offer to promote them to other customers if they do a good job.

Outside coding

Be ready to write excruciatingly detailed specifications and testing procedures.

Frankly for a one-off outsourcing doesn't make sense. You'll spend too much time & energy detailing what needs to be done and how it is to be done and when what parts are due and how to determine what was done properly and how to resolve problems... You'll then spend many hours overseeing those points as well as answering questions, resolving unexpected issues (things that were they done in your office would be settled over the water-cooler) and of course revising everything as the situation evolves. With all of that overhead it's cheaper & more efficient to just contract a bunch more coders locally and keep 'em under your thumb.

Where it does make sense is when you want a portion of code written that has fairly clear specifications and you're looking to get into a long-term relationship. There you can amortize the costs of the startup and learning process over several years or projects and get some real savings. This of course assumes your company is structured so that it can plan long-term and is stable enough internally to work with a bunch of outsiders in a possibly different time zone.

Honestly though I've heard of such companies I've never seen one myself (much like unicorns.)

I work for such a company, so I know

If you send stuff overseas, you're using many undertrained workers. Some tasks are suited to that, like Y2k or bug fixing ('many eyes make shallow bugs'), or where the goals are very explicit (format 'a' convert to format 'b'). Design and technical work are *not* a good idea. I'm one of the guys that cleans up after the overseas folks screw something like that up, and it is very common that I'll have to start from scratch.

If you have something a horde of interns could be thrown on, it's a candidate for overseas. Otherwise, don't bother.

Re:Laws and Languages

It's not just languages - it's business and technical expectations. It usually works fine, as long as you understand that you're outsourcing, not micromanaging. When I've worked with Indian consulting firms in the past, they've typically got a couple of experienced foremen who've worked in the US with US firms, who speak English just fine and know US business environments, and then a group of workers who at least read and write English adequately even though they may not all speak it in real-time with Silicon Valley accents and may be just off the plane. So you'll do most of the interaction with the lead guys, and they may go discuss it with their crew in Indian-accent English or Hindi or Kannada or other regional language.

But in any All-American outsourcing environment you'd often have similar interactions, where the lead Speaker-to-Techies huddles with his krewe and comes back to say "Yeah, we can make the Frobulator do that, but it'll take two more weeks", or the Speaker-to-Marketers goes to play golf and comes back saying "Wait, it's not telepathically controlled and adding buzzword-of-the-week-compliance will cost how much extra?!?"

Legal issues are a different game - you've always got that in an outsourcing or consulting environment, and you've got to be more careful if you're doing international business. But many Indian consulting firms have US parts to them, and you write the contract to specify the customer's state as the defining law, and you realize that the contractor will use the expertise they gained doing your job as a stepping-stone to charge more money for the next job for their next customer, just like you would if you were consulting :-) Since this is Slashdot, there's the extra legal wrinkle of open-source code - you're no longer paranoid that they might take code you paid them to develop and sell it to their next customer - you know they will, because you're requiring them too. So just make sure there isn't too much scope creep in the statement of work.

As with everything it depends

I've seen US based contracting companies churn out a lot of utter crap in a short time. I've seen other projects' attempts at outsourcing overseas cause extreme misery.

On the other hand, my one first hand experience working with a bunch of guys from Romania worked out pretty well. Most of them were fresh out of college and the job was paying several times the national average salary so they had a very strong incentive to show us that they could do good work. We made damn sure everything was documented and a team of us would visit their shop several times a year (Along with weekly teleconferences.)

Basically I think it boils down to a matter of having the resource and managing it properly. If your management sucks and your product has no design, your contracting company (In the US or abroad or even in-house really) is going to do the best they can and fake it and bluff where they can't. They'll never tell you "The spec needs to be clearer in this area." If you manage the project well, have the whole design speced out in advance of outsourcing it, and get everything in writing, your outsourcing will be successful (And you'll end up spending about 2/3rds of your savings in project management.)

I think most of the projects I've seen fail have failed because of the lack of a well thought out design and poor project management.

Re:Lots of things

I worked for a manager (director, acutally) that would try and pile inside and outside people on a project to get it completed faster. We eventually came up with the "He would get 9 women pregnant and expect a baby in a month!".

There are dozens of other things to a development cycle than just oursourcing 'certain problems'...

Several related experiences

Over the last few years I've had several opportunities to view the problem of outsourcing development from different perspectives. Primarily I've been in the business of picking up failed projects and teams and making them successful, but I've also lived abroad and run development projects from there.

I've seen projects fail when done by internal teams, US contractors, and overseas contractors. Although there are many reasons why projects fail, most projects fail because of poor leadership. Poor leadership can take many forms: failing to fire the jerk whose blowing smoke and slowing everyone down; applying too much, too little, or inappropriate processes; failing to apply pressure and set deliverables; applying too much pressure and setting unreasonable deliverables; poor communications; inadequate analysis; too much analysis; poor hiring practices, etc, etc, etc.

Adding contractors to the mix is not an always/never kind of deal. Contract/outsourcing (US) can solve a variety of problems. Generally it's done for a few different reasons: 1) managerial uncertainty (fear of failure), 2) missing temporary skill sets, 3) lack of strong internal development teams, 4) short term development needs greatly exceed long term needs. Of these, 2 and 4 are valid, whereas 1 and 4 are just looking for trouble. Hiring outsiders must be done to solve a SHORT TERM manpower need. This isn't to say that a manager who hires an outside company for the wrong reasons won't succeed, but it's definitely a roll of the dice.

Running an outside development project has ALL the same problems as running an inside one PLUS a few others.

The first thing to remember is that it's not a company that you're bringing in but a group of individuals who will act as a new development team on your behalf. Like any team, these people can have a range of skill levels. Many contracting companies won't be able to let you meet the developers they bring to the table before you've actually inked a deal (the big ones like AC, EY, KPMG, etc are especially bad in this respect). If you can meet the team and literally interview them before the fact, then you should. If you can't, then you have to be ready to get rid of people and ask for others at no cost to you. One of the impediments to doing this can be the project managers that such teams bring with them. Frankly, the PMs at consulting companies are probably much better than the PMs that most companies have internally. The one drawback they have is that they tend to protect the interests of the contracting company FIRST and your interests SECOND. This means that you need to be more aware of his or her individual tasks and activities than you would be of someone who works directly for you. (Manage the relationship closely).

The second thing that is critical is up front analysis. Most contracting companies want to come in and do a requirements/needs assessment first. The result of such an assessment should be a clear set of requirements and general documentation that will form the basis of your project definition. One of the problems with this is that the 100-page (mostly boilerplate) result is not the best way to help YOU understand your OWN requirements and needs. If you don't understand your OWN NEEDS, then failure is right around the corner. If you have the money and time, go ahead and let them do the assessment, but only after you have put together your own basic requirements. As your requirements are gathered make sure all the stakeholder are personally and INTIMATELY aware of the details of the requirements that are gathered. Remember that this process is garbage in garbage out. They may turn out a bunch of junk requirements if your stakeholders haven't taken the time to think through there own needs. Bringing in outsiders can give stakeholders a false sense that their needs will "automatically" be met. (Manage the relationship closely)

Assuming that you have "good requirements", whether generated internally or externally, the challenges aren't over. The nature of any sufficiently large development effort is some degree of iteractiveness. That means the developers need to be able to COMMUNICATE with a variety of people throughout your organization. Some of these people are technical, and some aren't. Either way, if communications breaks down or becomes formalized to death, you'll get something that "meets the requirements" even though the requirements are wrong. The internal/external nature of the relationship can make communications doubly difficult. Sometimes people may be knowingly or subconsciously sabotaging the effort (a developer unhappy that outsiders were brought in says "I'll just let them go ahead and fail" and sure enough they do). Communications, collaboration and intimacy are the nature of the game. (Manage the relationship closely)

The last issue is the final handoff. Products rarely meet all expectations, and most have some degree of fixing and maintenance after the fact. The final "handoff" usually involves a bunch of documentation (half to 2/3 of which is either boilerplate or wrong). Not surprisingly, this is not an ideal way to communicate. Most communication is an iterative two way process. Even face-to-face conversations frequently end with two people walking away with completely different ideas about what was said. If the team (or individual) who takes over the system doesn't adequately understand/respect what s/he's getting then you can pretty well bet that it'll get junked/gradually-rewritten-over-time. Ultimately, some period of phasing out is desirable to let the new and the old transfer adequate understanding/respect to allow the transfer to succeed. As long as you manage the relationship closely this can be done.

Those of you still unclear on the concept: manage the relationship closely.

Having said all that about US contracting, how does it all apply to overseas contracting? Generally there is only ever one reason for doing overseas contracting: money. There can be little doubt that this is a valid motive, but being cheap (and oversees contracting IS CHEAP) doesn't solve the problems of doing successful development.

Developers in other countries are just like developers here: some suck, some really suck, and some kick a??. Unfortunately, you'll not get the chance to meet to many if they live 10,000 miles away, so you'll have to pay more attention to the code and design documents. Remember: CODE IS TRUTH! Do regular code reviews, bring their milestones in house and have someone try to figure out how they work. If things are going badly, remember the principle of sunk costs and abandon-ship/demand immediate change. (Manage the relationship closely).

Foreign countries CAN mean language barriers. Make sure that individual goals and milestones are meeting your expectations. Don't let them go to far down a blind alley.

If you have the time to do these things, you have a well-defined project with well-defined goals, and you are lively and unprejudiced, then give it a shot. Unfortunately, at least one of these probably doesn't apply to you, so you should probably do it in house:)

Kevin Barnes
Sr VP of IT
OneSecure
[e-mail]

Send someone over

First the horror story:

Mid last year my company was in a bind. We had a large amount of development to do, and not enough people to do it. The solution: off-shore outsourcing. We basically handed these guys all the specs, gave 'em a rundown and let them go. The end result can only be described as crap. I mean really, really bad. If you can think of a negative thing about out-sourcing, it happened. In the end I just re-wrote the lot.

The next attempt:

Late last year my company got another large project. Once again we did all the analysis and design, but didn't have the resources to code it in the time frame we had. Once again, we used an off-shore development house (the same one, even!). But this time, we sent two people over in a team leader / advisory role (I was one of them). This time it went much better. Here's a few of the benefits we saw:

• Because we had an interactive role with the outsourcers, we could identify any potential issues before they happened.
• We were able to teach them our coding/documentation standards and enforce them on a day-to-day basis rather than every other month. We did regular, on-site code reviews to make sure we didn't get sloppy code.
• Many of the out-source developers were hopelessly inexperienced in our development environment and the technologies used. We were able to identify the guys who were struggling and give them the extra attention they needed to keep up.
• Any specification ever written contains vaguries and some ambiguity - basically the issues for the programmer to figure out. If it didn't, then it's a waste of time - the person that wrote the spec may as well have written the code. Since we physically there, we could answer any questions that the guys came up with on the spot rather than waiting half a day or longer for email. This prevented huge amounts of potential misunderstanding.
• We were able to give consistant, regular feedback to our management on the state of the project. This was a big one. One of the problems with outsourcing is that the people you give the work to, because they're hanging on your money, are almost always hesitant to admit that they're struggling. With us there talking straight back to our management, there was none of that.

The end result: Quite simply, it worked. My company didn't get it at the absolute basement price they might have without sending people over to be part of the team, but it still turned out cheap, and the code worked.

Can of Worms

This was my experience with a company in India:

1. Difficult to get in touch with people because of the time difference (something like 12 hours ahead over there.) My cell phone wouldn't take incoming foreign calls nor could I make outgoing foreign calls (didn't want to pay for them anyway). This left me chained to my desk for 7:30 AM phone calls.
2. The calls and faxes will get expensive b/c all meetings must be conducted over the phone, not in person.
3. The company I dealt with made a lot of promises and did not deliver. They were given a site to reverse-engineer using a new technology (went from ASP to WebObjects). Even with source code and complete access to the server's configuration they were unable to complete the task without my team writing 80 pages of technical and functional specifications for them.
4. The time it took us to right the specs, we could have coded the site ourselves.
5. Certain foreign companies don't like women, it is a cultural thing. If the CTO (a woman) gave them instructions, they waited to confirm with the Project Manager (a man). This was problem for us. It may not be a problem for you.
6. The final code was mediocre and completely undocumented due to the language barrier.
7. If you go forward get a fixed price agreement for the complete project. Don't do any weekly rates or billing system that allows them to report hours. We were over budget by 25% because they took longer than promised.
8. Suffice to say, I would never do it again.
9. Good luck.