Slashdot Mirror
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?"
If, on the other hand, it is Yet Another Accounting System Front End, yeah, outsource it... okay, so this one is done in XML rather than using Curses, big friggin' deal, an accounting system front end is an accounting system front end...
-E
Send mail here if you want to reach me.
Unfortunately, here's what happens in real life:
You're a designer. You've laid out this neat architecture. You've documented it out the yazoo. Management says "That's nice, where's the program?".
So you start writing the black boxes, one by one. They get done. They're tested, one by one, according to the test plan. They work. Management says "That's nice, where's the program? I don't see any pretty GUI graphics on the screen!".
You start chaining the black boxes together to create the back end services for the GUI. Ten days later management, in frustration, fires you and hires a new project manager. The new project manager comes in, sees the project nearly completed, and assigns a programmer to finish chaining the black boxes together, something that takes another five days. Meanwhile he assigns another programmer to whip up a quick prototype GUI in TCL/TK.
Management says "Ooh, pretty pictures, we ship tomorrow!". The new project manager smiles, accepts his 25% bonus for delivery, tells the GUI programmer to tar up the halfway-working project and release it as version 1.0 (complete with the half-assed prototype TCL/TK GUI), then sets the team to work on version 1.1, the finished version that actually works.
And that is how the real world works. Sad but true. Pointy-haired bosses don't want specifications. They don't want software engineering. They don't understand all this stuff about design for maintainability. They just want pretty pictures on the screen that look like they're doing something (even if they're not), and if they don't see pretty pictures, they don't believe that work is being done.
Try telling a pointy-haired boss that the GUI is the easy part and that you need to put your experienced people on the back-end stuff and hire a newcomer to the company to do the GUI. I dare you. He'll look at you like you have horns growing out of your head. So what ends up is that the most experienced programmer in the company gets assigned to whip up the GUI and yeah, he can do it in 4 weeks (as vs some newcomer to the project who'd take 8 weeks), but that's 4 weeks further behind that the back end code (that does the actual work) gets.... meaning no net savings in time. But pointy haired bosses think that the pictures on the screen are the only thing that counts, and have no conception that there must be code behind the pictures to actually do things... and thus projects get written bass-ackwards all the time (i.e., pretty pictures drawn with GUI Designer tool to impress boss, then programmers charged with writing code to implement all the buttons and widgets... despite the fact that no functional analysis has been done on what the product needs to do, and no analysis has been done on proper architecture for the back end).
So it goes in the real world. If you ever interview me for a job, be sure to ask me "What is your dream?". My answer will be "to some day, some how, work for some company that manages sofware projects effectively and efficiently." Alas, I'm starting to think it's going to remain a dream for the foreseeable future... well-managed software development, outside of a few very specialized niches like aeronautic software, is virtually unknown. Otherwise Microsoft would be out of business, because there's no way that their buggy bloatware could compete with well-designed software delivered in a timely, efficient manner by well-managed companies... Microsoft is very lucky in that their competition has been folks like Digital Research, Borland, Corel, SCO, Netscape, and Novell, all of which began as effective companies but which degenerated over time to producing the same kind of buggy ill-designed bloatware as Microsoft.
-E
Send mail here if you want to reach me.
Python is one of the languages that's often mentioned as being faster to program in than C or C++. It is. I can write about the same # of lines of code per hour whether it is in "C" or Python, but my typical Python routine is about 20 lines long, while the equivalent "C" routine is about 80 lines long. But that does not, of course, reduce the design overhead, meaning that there really isn't that significant a savings in overall project time. It does, however, make things more efficient when you're trying to do something that's never been done before, and you're having to constantly build prototypes to see whether a possible design will work or not, and what the components would need to be for that design.... even if the final project must be in "C" due to other considerations, it might be worthwhile to prototype some things in Python, Perl, or even /bin/sh just to see whether it would work or not. But that's something to be done only for things where nobody has ever done it before and thus the "right" design is a mystery that must be discovered via both trial-and-error and analysis of the problem (and you may not know the full scope of the problem until you try sample solutions -- some problems are difficult that way!).
For most projects, I would say that choice of language is irrelevant to the ship date (though I would prefer a language like Java or Python that takes care of memory allocation/memory leaks and dangling pointers for me... I *HATE* memory leaks and dangling pointers!). It is, after all, perfectly possible to write object-oriented code in plain old "C"...
-E
Send mail here if you want to reach me.
Thank said, I have to agree with you 100% that outsourcing is not best used in the short-term. Rather, it reuires some dedication and long term commitment to get through the initial hiccups in order for it to work right.
So once you get to the "we're in this for the long term" you might just want to hire people in house.
Werd.
As a team developer, I have a rough time imagining how this could ever really be feasible. It's hard enough if you have an in-house developer that doesn't communicate enough! Does it usually take the form of having some CVS-kinda codebase that everyone has access to?
I'm curious what sort of projects have had good luck with outsourcing.
Apart from your generalisations, I think you cover most of the points. But these are differences not problems.
1. You will need structured communications. People think it's OK to decide everything around the water cooler and with ad hoc little conversations, which may work in a small little tech company but is no damn use for managing teams in other countries. Read a good book on project management, and get some proper structures in place. And if you can't handle working with other timezones you've got more problems on your hands than you think anyway!
2. Don't expect anyone to do you favours. If you got paid the salary they are working for you'd not do overtime either. Get a clear agreement, stick to you side of it and don't expect your supplier to do any more or less than their side of it.
3. Don't expect creativity or imagination 'for free'. My turn for generalisation now... I have heared it said that Indian programmers (I've not dealt with any others for outsourcing) don't approach the work creatively, and this a huge benefit. No feature creep. No chrome. No programmers getting bored and learning on the job with your code.
4. It may be that what you are doing is shifting your dull grunt work onto people who earn 1/10 of a U.S. salary. Fine. If you treat them like dull grunts, you'll get what you deserve. They aren't stupid, they are probably twice as smart as the average self-taugh Javascript weenie earning 35K a year (UKPS) doing crap code.
5. It's almost certainly the way of the future. Vast amounts of the repetitive work required by Western industry is outsourced to 2nd world countries. Sooner or later, programming will follow in the footsteps of textiles, toys and the rest. Might as well practice now!
-----
Yep. Speaking as a former consultant, that's often because the last item in the specification is the delivery date. You can't tell the client it's unreasonable, so you throw together as much as you can as fast as you can (which goes a long way towards explaining VB's popularity). And since clients frequently either don't have any documentation standards or waive them for this "critical, fast-track" project, it's a real nightmare for the staff people who have to support this stuff.
OTOH, I've also been hired to augment/port projects produced this way, too. Jobs like that help balance your karma out.
Just junk food for thought...
There is another "hidden" risk in custom programs - the talent pool isn't readily accessible to the company. When you have a developer in house, you can pickup the phone and go "Hey fred, how come xyzzy doesn't work?" and get an answer now. Maybe even a patch.
It's more red tape, which means getting things fixed, new features added, or whatelsenot will take longer. You won't be saving any time by outsourcing because there needs to be a tight communication channel between the developers and the users. If that channel isn't there, you get Microsoft products but with worse reliability.
Just my $0.02.
(1) keep tabs on progress, and
(2) answer technical questions and clarify specifications.
We found that unless we had people there, stuff didn't get done. We started out with the idea that it would all be hands-off but ended up keeping at least a couple people there at all times. A project manager type and a techie.
As the "techie", I spend about 6 months last year in Hong Kong helping our technology partner there make on-the-spot UI and design decisions, figuring out where the problem areas were in the applications they were writing for us, and making sure their needs were being met.
One big advantage of being there is that conference calls can seem overly formal. Our partners didn't like to convey bad news over the phone to a large group of people, but I could ask in person and get an honest answer which _I_ then relayed to the same group of people. We got more honest answers more quickly that way than any other procedure we discovered. Also when I sat in on the conference calls I could see what was going on in terms of body language and such. And it helped reduce language difficulties.
Rather than being there continuously, our overseas team would spend up to a month at a time there, then return home for a week or so before going back. That made it much easier to pay bills, stay in touch with friends and family and so on.
I play Nerd-Folk!
OTOH, I'm sure that if you shop really well for an outsourcing place, work with them on specs and requirements, and agree on a reasonable delivery time, you have a much better change to get good results.
one interesting possibility would be to use open-source-like development methods. the code doesn't need to be open source, or available to the public, but you can set up development in the typical OSS way, with all communication between developers being done on mailing lists, with an internal CVS tree, and encouraging everyone to keep an eye on the patches, and to read other people's code. then you can have one or two people from the "client" company on the project, while the "outsourced" company throws as many developers at it as it considers appropriate. since there is constant contact at the techie level between the two companies, you greatly diminish the possibilities of "bad surprises".
The primary problem is not language barrier unless you are trying to outsource something to a country like F... which prouds itself in making sure that its cittizens do not know a foreign language so that they do not pollute their native one.
The primary problem is cultural and woking style differences. Just a few examples:
IMHO - outsourcing to 1 or 2 is a process that with proper management brings reasonable results. Outsourcing to 3 is the most idiotic idea of them all. You need a very high level of knowledge in house to make sure that the specification and project assignment is sane. At that level of knowledge it does not make sense to outsource to 3 at all. It is done by the same companies and people that run HB1B slave shops. Where the legal department takes care of the bugs and performance issues (so that they are never known and quality of the product is neve questioned).
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
Reading your post, I laughed out loud. Your list of problems accurately describes my experience with MS Access. This is why people develop their own software :)
Poor documentation: Haven't really seen any for Access.
Buggy and/or half-working menus/programs.: Several months ago, we were using MS Access to track customer information. One of the columns had a maximum length of 255 characters. All the same, an employee entering data was allowed to put in more than 255 characters of information into this field and corrupted the database. Any attempt to open the database complained that the data in that field was too long. The repair tool could't fix the file, either. We had to restore from a backup, and reenter all the data from the last two days.
No support if something goes wrong... This sounds almost EXACTLY like what happened to us. We called Microsoft and were charged full support rate to complain about a program error that I would expect of a first year CS student in their very expensive software. They were totally unhelpful, had never seen the problem, had no solution to the problem, and ended up refunding our money.
I've talked with people before and seen horrible results from outsourced products. Its great for manufacturing but not always good with something strangely artistic like coding. Everyone sees things a bit differently which can lead to alot of problems when it comes down to solving problems. Outsourcing can of course get you a finished result for a lower cost but you don't want to outsource to a bunch of programming houses in order to get something programmed faster. Too many cooks in the kitchen afterall.
1. Design your application to the most specific of details, outline everything you want done and how you'd like it done. Don't leave things up to a guess or some outside programming manager (not to insult anyone but to say that you want your application programmed how you want it programmed).
2. Make sure you keep in synch with the outside house you're working with, if you have changes (keep them few and far between) or additions make them as well documented as everything else and get those revisions to the outside people ASAP.
3. Demand excruciating documentation so if you ever need to work on the code in-house you won't be left into the dark as to how things are working or how things were done.
I'm a loner Dottie, a Rebel.
We have another program that is incomplete. Only part of the functionality was completed. Shall I go on?
Get a support contract if you are going to outsource.
Make sure that you have complete documentation of what was done.
Make sure you have some techies to work with the group that you are outsourcing so that you have some knowledge in the company.
Of course the big thing depends on what you are outsourcing too. If you are outsourcing ads, then believe it or not the industry standard is doubleclick. I'd use someone else if it were up to me though. If it is a program or a system and company X or company Y will get the job done, do make sure you have documentation and some kind of support deal. This is in case things go wrong.
The biggest problem with outsourcing is that they never know how you are going to use the product. Really use the product. Yes you go over all the details with them. You scope out the project. But there are ALWAYS issues that fall between the cracks and they popup up after the outsource group is gone. ;-)
~~~~~~~~~~~~~~~~~~~~
I don't want a lot, I just want it all
Flame away, I have a hose!
Only 'flamers' flame!
If you want something done right, you've got to do it yourself.
My company has had this lesson driven home to us many times.
Whether it's coding, networking, translation services, etc, EVERY TIME we let another company handle it (whether they are partners or contractors) they either take to long or totally screw it up or both.
In the long run, it always turns out that we could have done it better, faster, cheaper ourselves.
just my experience.
I would like to add to my previous post and basically retract it. I was not directly involved in the project mentioned above and was basing my statements on bad information and recollections. I was under the impression that the project had completely tanked and was over with. I was wrong. I would like to apologize to Rose-Hullman and anyone involved for any false implications.
-B
I was recently fortunate enough to get to work with some code that was written by some other company. The main problem that I had was that they didn't code with maintainability or expandibility in mind, but rather towards a particular solution. While it did rather well for its intended purpose, it was utterly miserable to try and get it to work with anything else. I ended up rewriting the whole damn thing.
See you, space cowboy...
Who has to support the code?
If you, then you'd better write it.
If throwing more people at it will get it done faster, then I guess 2,000 people ought to get it done in about an hour.
Of course, 1 & 2, and to a certain extent 3, should be followed for ALL projects, outsourced or handled in house.
First of all, the most important factor is the WHAT. What are you trying to accomplish with the project; what technologies are you using; what language; what environment, etc. You will find an easier time outsourcing projects with known technologies and implemented in known languages, than trying to teach something totally new to some other people.
Second, even if you're using known technologies, try to figure out how much time it will take to even make another team from another company get up to speed with what you're doing. Take in consideration the following:
Now, there are several companies outside of the US with great resources and many capable people. You can give a 'small' project to the company to measure performance, quality, time-to-market, etc. and if you like their performance, maybe consider them for a more complex project later on.
I hope this helps.
Signatures are supposed to be funny?
I knew a Belgian guy who invested in a Russian/Latvian code shop. They hired dozens of programmers at similar prices to produce various coding projects. For a while they were earning a ton of money from western companies, but that has been drying up lately as the economics shift.
One of the projects they did was a printer driver, it took 14 programmers about 3 months to code and test the driver. An american friend of mine who codes like crazy was visiting to oversee the results of the project. He mentioned he had, alone, written a similar driver in just a week, but the testing and bug fixes had taken an entire two weeks to get it right. That is the difference in output you might get depending on how well you manage your resources.
The biggest problem is in making sure the work is done to your spec and on schedule. You have to set up a fairly large department just to manage the foreign contract and ensure everything is happening as planned. This doesn't work for short term projects, your company had better have a plan to see this through several years before they see any significant cash savings.
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
There are some very good minds in the subcontinent.
I would like to point out that when last working there I visited a clothing manufacturer. They had two lines of machines in a big warehouse. One one side there was a huge bank of electric sewing machines; on the other was a huge bank of pedal-powered sewing machines.
When (not if) the power, went down all the employees stood up and walked across to the machines on the other side of the room, sat down and carried on working.
This is not possible to do with computers, unless you have some very enthusiastic donkeys tied to a generator.
On a more serious note I have worked on a number of projects where we have outsourced and it has helped enormously where we seconded one of our engineers to the third party to join the coding team. This ensures that nothing is swept under the carpet and that documentation is done correctly.
Slashdot Beta should die a painful death.
I thought that something around 90% of coding effort is dedicated to maintance.
Off-site development, especially other-side-of-the-world development, is a less interactive environment than longterm-coworker-in-the-next-cube development. If you need to be highly interactive, you need to be nearby (maybe not geographically, but at least in terms of shared knowledge and interaction speed.) A well-defined project can work; a whiteboard design discussion is a much different environment. If you're handing off something to people you don't know well in a much different environment, it needs to be better-defined, and big enough to handle the learning curve you'll both go through. Smaller tasks often have as much overhead as bigger ones, though if you're going to outsource multiple projects, it's worth trying the small ones first rather than the bet-the-company projects. Learn what kinds of interactions work well and what kinds don't.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
My company is in exactly that situation at the moment. it's working reasonably well. it could be a total disaster, so here a few pointers:
a) MAINTAIN CONTACT. i can't stress that highly enough. MAINTAIN CONTACT. constantly. daily, if possible. it will make them, and you, feel less detached and keep the goals focused.
b) get everyone on an Instant Message sort of thing. (ICQ/AIM/MSM etc) this way everyone can talk easily, and news will travel quickly. it's easy to just say hi, that way.
c) ensure they have an office, or contact of some sort in your city, who is linked very closely with the programmers. someone you can have meetings with, and convey things that don't work over phone lines or ICQ. also, that situation is more condusive for getting the programmers over to meet you and work with you.
those are the most important points. make sure you feel they are a part of the system, that they feel they are too. the situation can work as long as you can project manage from a distance and they have some self-discipline. one thing that may help is to get one or two of their lead developers to work with you for a week or so, so they get into the rhythm of your project, then they can go back and lead the project much more accurately, as they'll feel more part of it.
also, bear in mind that programmers from "other countries" write code differently. not necessarily due to the language barrier, causing possibly incomprehensible comments, but coding styles actually vary from country to country too. having learned to paogram in one country and moved to another, and worked with people in 2 other countries extensively, i have noticed many little quirks and different ways of going about the same task. the point is here that the resultant code may be difficult to maintain, or at least to get in to to begin with, compared to others.
it will never be perfect integration, but a good solution will make you feel like you're working with someone in the next building, rather than the next country. good luck!
fross
When I came in, the project was back. I had specialized in Expert Systems in college and I could recognize all the concepts they used to create one, but the code was obfuscated so that we would have them maintain it. The process for entering information was beyond the reasonable learning curve for anyone who was not a programmer. We would have to dedicate a full-time person just to be able to enter the data. This had been intended to be maintained by our technicians for the use of call operators and another version to go on the web. After a few weeks of trying to decode the information, my manager and I flushed the project as unusable without sending good money after bad.
I don't regard this as a death sentence to outsourcing, but it is a VERY good idea to know what the outsourcees want to get out of the project. If you make it clear that a well-functioning project up to detailed specs will probably earn them a boatload of more business, you shouldn't have too much to fear. The group my manager used wanted to sell the project at a loss and charge two or three headcount for maintenance ad infinitum. This didn't match my manager's desires at all.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
I've had one experience and it was bad. I'd hoped to hire a programmer to free up time for me to work on the "bigger picture". The code that was created was late, buggy, unreadable and I'll have to start from scatch to expand on the feature set. The programmer didn't follow instructions and would waste hours and days stuck on a problem that I could fix in a short time. Conclusions: Communication - lots of checking of the progress of the project (2-3 times a day). Check that there is progress, that the code works, that it is well documented and that it actually does what you want it to do. If you're not happy after a couple of days, find someone else. Otherwise it'll only get worse.
I have seen major software development project done with overseas (Indian) programming outfits. The ones I have seen have been (a) large undertakings, and (b) generally successful. HOWEVER ...
There is a lot of overhead and up front expense involved in these projects (training, project definition, development of specs and milestones, language barriers, time zone barriers, etc.), and the LEGAL overhead is most often ignored by companies looking to save a buck.
Unfortunately, ignoring the legal problems is the surest way to get into big trouble.
The following issues are some of the big ones for your company "A" (and its legal team, which will have to include lawyers from both countries) to think through before hiring "B" to do the work:
1) Assuming that A wants ownership of the source code deliverables (and why not?), does the law of the country you are in impose any special requirements on assigments of copyright and patent rights from B to A? What about B's programmers -- does A need an agreement directly with each individual programmer or is an agreement between A and B sufficient?
2) How well (if at all) do the laws of B's country protect against unauthorized disclosure of trade secret and confidential materials if B turns out to be ill-intentioned?
3) Does B's country recognize a choice of law provision in a contract and are such provisions respected by the tribunals in B's country (e.g., so that the law of New York, California etc. will apply rather than Russia's laws)
4) If B fails to perform under the contract (or worse, discloses or misuses confidential information) is there any effective remedy? Is it feasible to get relief from the legal system in B's country? Even if U.S. law will govern, that does not provide any effective remedy if you still have to travel to a third world country without any real legal system to enforce any judgment you get.
5) If the work is developed outside the U.S., transfer of the intellectual property (e.g. source code) to and from the U.S. may be restricted by each government (and therefore you may need to get government blessings both from the U.S. and B's country). Also, transfers of intellectual property across borders sometimes creates complex tax issues for which reason A's accounting firm should be involved and advise on how to structure this. Finally on the tax issue, any royalty payments for software what B owns or will continue to own will be subject to withholding (10% or more) and more complex tax treatments; again the accounting firm will have to help structure any such deal. On the plus side, it is possible to create a tax haven for overseas income by developing the source code/intellectual property overseas.
6) If the project is substantial, A will probably want B to agree to a non-compete. Are non-compete's violative of the public policy in B's country (I think they are not enforceable in India but I could be wrong about that). If you don't have a non-compete, and you are spending a lot of money to train B's programmers, how are you going to prevent B from using the training you provided to service a competitor?
Jeff Norman
Outside programmers don't have your big picture. They will probably never have in mind how you might use that code in the future. In other words, they have naught motivation to be flexible or write code that can be flexible.
So if you outsource code to do foo, the code will do foo. It probably won't, without lots of reworking, do anything other than foo, no matter how close to foo what you want is.
An idiot coorperation outsourced all of thier coding to another group, to write a certain type of media player. The media player does exactly what it was contracted to do, which wasn't much. Compare this to other media players, which usually try to be flexible.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
Amazingly enough, I work for a company that has received an overseas contract. =) Let me give you some views from the "other side".
:)
First of all, as someone mentioned above, specifications are a MUST! And detailed specs are a MUST. We're lucky in that we get alot of le-way in terms of the technical decisions, however, in the industry that we work for, there are countless details that do not pertain to computing (or design in general) that we must follow. What helps for these details is having someone (the project manager) come overseas and work with us for a week or so every couple of months.
Another thing that helps immensly(sp?) are web-based scheduling and bug tracking tools. We just started to use TWIG, a resource management tool. It's fast, easy to use, and free!
Other than that, remeber that just as with any project, a good, solid design and specification at the start will ease the entire development process right up to release. Good luck!
Chris
-- Humans, because the hardware IS the software.
...in particular, their intellectual property laws. "Work-for-hire" laws are not internationally uniform, so they could end up with rights to the work they've created if you're not careful...
An experience I had a few years ago which may be relevant.
A company I freelanced for had outsourced their IBM mainframe legacy systems maintenance to a 3rd party. I had to do some modifications to print output streams from the mainframe to accomodate a new inserter (changing barcode positions and formats..yawn). Anyway all the company had to do for us was change some JCL to accomodate my programs to pre-process the print stream before printing. Three months to code and test my part of the deal, then another 3 months still waiting for a correct set of JCL from 3rd party. I ended up getting permission to do the job myself (about 2 days work - JCL if you are not familiar with it is very very simple grunt work). Unfortunately we had by then hit the Y2K change freeze so changes had to wait (I didn't, left the updates ready to be implemented and left not wanting to sit around thumb twiddling for another 2 months).
The reason as I later found for this ineptness was that the company also considered JCL to be grunt work and so assigned a bunch of recently graduated employees to do the work. JCL while simple still needs an appreciation for the system you are working on and what you are trying to achieve, as well as a basic understanding of the syntax.
The point of this is that if you consider the work to just be grunt type work, then so might they - and you may not get anyone working on it who has the relevant experience to do a good job.
Additionally as a freelancer I've worked for a lot of dofferent companies (in the UK) over the last 10 years and without exception those that had offloaded all or part of their systems to 3rd party maintainers (after an initial honeymoon period during which they became locked in) suffered poor service. Basically the 3rd party maintainer makes a profit by using less people - one sys admin could be dealing with the machines from more than 1 company for example.
I'd advise against it for your long term mental health basically.
*BenZilla*
write up a simple list of the reason's you think it would be better FOR your company to do it in house and then submit it to your manager? I mean if you really feel that this is unnecessary/greater burden/could **COST** more in the long run I wouldn't see why your company would not heed your suggestion.
Sig it.
You share your specifications and propietary code with an overseas shop that has a much lower overhead than you.
As long as they don't try to Detroit you (ala Honda in the '70s) and produce a competing product that's cheaper and better, you should be fine.
You can make them sign a NDA, of course, and hope their foreign courts are more sympathetic to your interests than their own. And then hell will freeze over.
Also look at their legal customs and laws. Who will own what? Don't assume contracts are handled the same way there as in your own location.
Good Luck!
Cleara
Yeah, I'm so glad these things don't happen when developing in-house.
You will only get as good as you give. If you do not provide the overseas development team with a set of requirements, and if you do not require a design specification from them first, and if you do not review said specification thoroughly, you cannot expect to receive project code that can just be handed off. You will be lucky to get something that works and does anything even remotely close to what you desire.
One of my company's clients is in this boat - their specs were not thorough, and they had a decidedly hands-off approach to managing this overseas team. They got a huge, bloated mess of code and nobody was happy.
I believe it can be done but lobbing stuff to overseas developers and wiping your hands of the matter will burn you! Your responsibilities aren't relieved; they just change.
We have been using an oursource dev shop from India for the last few projects. (200k to 1 mil $US range projects). It CAN work if you do a few things correctly:
1) Give them a trial run on a smaller project.
2) Design SPEC the bejesus out of what you need.
3) Provide lots of sample code from your dev shop for them to look at. (set explicit expectations)
4) Require code checkin daily to YOUR source code management location. Even if this is one of their staff tasked with moving all source to your server. (accountability. you ask this from your own developers right???)
5) You get what you pay for. Your $100 US per hour c++ guy is the same quality as the $50 per hour overseas developer. That has been my experience anyways. Don't use bargain rate overseas developers, they are very inexperienced.
BTW once you find your groove with an outsourced dev shop, (meaning they staff accordingly for your workload) you can really speed up your development cycles.
Hope that helps.
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.
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
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.
----------------------------------------------
-*- Any technology indistinguishable from magic is insufficiently advanced -*-
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?
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
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.
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.
Seastead this.
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.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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 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!
UserAdvocate: The voice of the user
Want to outsource overseas? Here's some Do's and Don'ts, based on my own experience as a code provider
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.
Zoe Brain - Rocket Scientist
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. :)
http://dtum.livejournal.com
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.
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 don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
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.
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
There are dozens of other things to a development cycle than just oursourcing 'certain problems'...
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
kbarnes@onesecure.com
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.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.