What Pitfalls Exist When Outsourcing Code? 167
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?"
One bad experience... (Score:1)
We outsourced the vast majority of a year long project to an eastern european company. The code came back buggy and slow as hell. I'm currently doing a complete redesign... Sigh... But, that's not the worst part. The worst part is that the developers responsible for the current mess think they're the greatest thing since sliced bread. What's more, I recently found out that before this assignment, their only programming experience was a three month intense training course, after which they were told, "You're all better than any American programmer," and from their attitudes, they believe it! I can take ignorance when people are willing to learn. I can take arrogance when it's backed up by ability. But arrogant ignorance is intolerable!
How did we get into this mess? A former IT honcho (now fired) was in bed with the foreign company. And, due to the contract he signed with them, we're stuck with at least two of their programmers, no matter what they do, for another year. (A little "guarenteed work" clause...) Joy.
Re:Problems (Score:1)
because of this, we have had to have their lead guy come over a couple of weeks a couple of times a year.
fortunately for our team, his skills are good and his english is excellent.
it's nice to think that because of the time zones development can occur 24 hours a day, but that is a load of crap. If he were here, AT LEAST the same amount of development would be getting done during our work day and possibly more. After all, he can't call me up at home in the middle of the Indian work day to ask me questions nearly as easily as he can walk to my desk and ask when he is here in the US.
generally, avoid (Score:1)
unfortunately, in some companies, cheap contractors really do create a headcount mentality. i've wasted too much of my life cleaning up "cheap" code because the contractor didn't understand (the language | subtleties of the underlying model | software | quality | anything beyond cranking the code). and of course it doesn't matter "because they're cheap".
it has been known for big foreign contracting companies to treat *you* as a training camp. let's not get second person here - *I* have seen BFCC treat *my* company like a training camp.
caveat emptor. but generally, don't "emptor" (no latin, salva mea)
[anonymous for obvious management baiting reasons]
Re:Problems (Score:1)
Re:Can of Worms (Score:1)
The project has significantly improved. The client personnel were slackers that punched in at 8:05 and punched out at 4:55 being certain to take full 1 hour and 30 minutes for lunch and numerous smoke breaks, coffee breaks, attend various diversity/other touchy feely meetings, etc. Productivity has soared. There have been some issues managing dual site development and maintenance (i.e. conference calls for meetings, learning curve issues). There has been the expected hump in the budget while transitioning knowledge and tasks to the off shore staff, but this is a long term project and their salaries are roughly 1/3 of what we have been paying for on shore development.
The quality delivered has improved. The work ethic of the off shore personnel is better than that of the client personnel.
What the consultants and off shore staff lack in years of experience is balanced by motivation and enthusiasm that is not displayed by the client personnel who spend the majority of their time bitching and moaning that the consultants get the best opportunities.
To assume that the off shore staff cannot learn the system as well or better than the in house staff is ethnocentrist at best and racist at worst. When outsourcing fails, it fails because it is managed poorly and if that is the case, maybe you should outsource your management team too!
3 Kicks at the Can (Score:1)
One of my first jobs was to take an application entirely outsourced and make it work. The developers had a clean slate to work with, but were incompetent, so the app came in riddled with bugs, including one of the most startling I've ever seen. I've no idea what the code writer was trying to achieve, but what he actually did was:
1) get the 3rd character from a string 2) add its integer value to a pointer and 3) dereference the result
In the English version, this miraculously yielded the right address. In the French version, it did not.
The 2nd experience was with a Latvian company in the early 90's. The pitch was that no problem was too big to be overcome by human waves of highly educated Latvian slave programmers. I have no doubt that the Latvians were much smarter than we were, but that proved to be of little practical benefit, partly because it was difficult to come up with large, self-contained projects suitable for "fire and forget" development. Also:
timezone impeded telephone communications
geography/air routes impeded physical communcations
there were enough cultural differences that business logic and user expectations had to be spelled out in far more detail than would be needed by a native developer
Finally, we recently hired a Bay-area company to port an application. Porting an existing application seems like a well-defined task, but it didn't work:
the slick and intelligent people you meet before the deal is signed bear no resemblence to the completely inexperienced people actually assigned to the project
the language and cultural barriers were just as big as if we had gone overseas
The bottom line is that making effective use of outsourcing is a complex and demanding task for management. In my experience, a subconscious appeal of outsourcing to management is the hope that it will make their jobs easier; the opposite is true.
Lots of things (Score:1)
Of course, with proper management, you can help to avoid a lot of these issues. Just pay attention - and be careful!
No idea why... (Score:1)
Brooks probably said it best... (Score:1)
I'd suggest getting your PHBs to read through Mythical Man Month (or give them an executive summary thereof). For what can now be considered an ancient text, it's still pretty damn accurate in a lot of what it says.
For what it's worth, if the concepts this code is meant to address have substantial learning curves, your management may be a little disappointed with the outsourcing results... particularly if the contractees have to harass the on staff coders to get up to speed with background stuff.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
Our main difficulty was the time zone difference. (Score:1)
Overall, the people who ended up coding for us were capable people, and they were usually easy to understand (though one or two had strong accents), but we ended up dropping their services because the time difference really had an adverse impact on collaborative projects...
--
-Rich (OS/2, Linux, BeOS, Mac, NT, Win95, Solaris, FreeBSD, and OS2200 user in Bloomington MN)
Not recommended (Score:1)
No more american companies writing my code.
Re:The pitfalls of outsourcing (Score:1)
Re:Success stories (Score:1)
The key is that the folks in VietNam work for us and have for a long time. Plus we visit them *every* month. We maintain tight communication via email, wiki, chat and the rare conference call. We have found an excellent manager and some *stellar* programmers. And we treat them well.
I can see where some people have problems: particularly when they're seeking silver bullet solutions. I think outsourcing, especially overseas, is tough to do ad hoc: it requires a relationship, an understanding of cultures, patience, and a *lot* of communication.
Like anything, it's not the right tool for every job but it's a good tool for the right job.
view from the other side (Score:1)
The success of a project largely depends on the communication and committment from the client. Few of our projects have gone over budget or have been delivered late unless we were forced into a "garbage in, garbage out" situation. If you don't know clearly what you want, or you think the specification will change, don't hire an outside group to develop the wrong system for you.
If you are worried that the outside group won't understand what you want, developing a prototype in-house and giving this to the outside team can be very helpful. Be wary though, prototypes have the unfortunate habit of being used as a foundation for production code. This can be bad as prototypes are often developed in a loose manner. Insist on a prototype for improved communications, but also insist on a fresh write of the system in order to have a clean foundation.
If you have some rather complicated technologies, like LDAP, or you have some specific coding standards you should share samples with the team. This will help make the source for the project understandable by your group.
Design or Implementation? (Score:1)
In my experience with one such situation, the group was pretty good at turning the crank when provided with sufficient information, but abysmal when faced with a 'blank page situation'. I.e. they could do raw implementation or extend an existing design, but possessed no design skills.
From the other end... (Score:1)
I get asked to write Linux drivers for various hardware. The guys who made the chip and their colleagues have the closest feeling with the chip and its interfaces. However, I have intimate knowledge of Linux.
So when you develop "in-house", there is one advantage, if you leave it to the "linux experts" there is another advantage.
So the question is: which way do the scales tip?
Brook's law doesn't apply if you add programmers at the beginning. Thinking about the project with a medium-sized team will make the design better. This will reduce development time.
If you start with one, two or three programmers, and later start adding more and more programmers because you're running late, you'll find out first hand about brook's law.
Also, a company wanting to start supporting Linux should hire us [bitwizard.nl] because if you hire a person to "also" do the Linux driver, soon, he'll be doing nothing else. So supporting Linux would cost you a full year-salary per year. We offer [bitwizard.nl] MUCH cheaper maintenance and support contracts. And for that money you can have one or two drivers developed every year too! Roger.
One good experience (Score:1)
1) Specifications. We wrote the full API spec as complete as we could (lotsa "result is undefined" spots), described exactly what the contractor company was to use in implementing the API (TCP/IP stack, H.323 stack, the following device drivers,
2) Performance. We included a test app and test cases that the coders could use to check their work. (Mostly ISO spec sheets and tests.)
3) Payment. 20% down, the balance on completion of the stand-alone code demonstrateably(sp?) performing to the specifications provided.
We got the first Beta in 6 weeks, and it was *really* close to what we wanted.
For us this worked because it is a standalone thing we wanted built.
The only real hassle we had was writing the specs in the first place.
-C
My experiences with outsourcing (Score:1)
Other "grunt work" projects ususally include fixing bugs, minor feature improvements, documentation or taming some out of control project build on crappy code. There are things that can't be outsourced well. The learning curve is very steep, and usually someone internal will eventually have to relearn it when it comes back.
However, I believe one of the biggest issue is reuse of code libraries. If you already have a well defined set of libraries that you use, you'd have to share. Of course, you outsourcers may be able to provide you with their libraries if they are more experienced..
i wouldn't do it (Score:1)
Nobody cares as much about your stuff as you.
Communication and Releases (Score:1)
- Communication: I wrote every day update letter to my customer and optionally have chat twice a day - early morning and tonight (we're on GMT-6). If customer didn't answered me I suspend activity and ask sales person to call by phone or call by phone self. Anyone in a team have a way to get emergency messages: SMS, pagers etc - so we can react on such situation.
- Releases: we're trying to release anything ASAP - everyday to have a feedback from customer. It helped much when we have both fixed-price or custom site.
- Legal: we'll not work if there are no agreement about cost, payments schedule and timline is accpetable. Sometime we declined offers to not get project failed. We have lawyer department and set of different contracts for different types of services.
- Payments: CFO worked in US that allow to solve problems ASAP, so our wires and checks never lost in space.
BTW I can provide anyone with list of 10-20 references from lead countries of the world (most from US) that are *COMPLETELY* satisfied with our service. Company currently have 300 techies and about 50 managers employed. We grow twice a year - so I sure someday we can handle VERY BIG PROJECT.
Re:Careful on lowball time estimates (Score:1)
Re:Can of Worms (Score:1)
This might not be a cultural thing. It is allways best to clear it with the project manager to help ensure that the project doesn't get out of control.
Re:Are you really this bigoted? (Score:1)
That's kind of an important detail, doncha think?
Use Co-Op (Score:1)
well, this is what to do (Score:1)
Re:There are places.... (Score:1)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:I work for such a company, so I know (Score:1)
Not foreign, but outsourced all the same... (Score:1)
In-house is always the way to go, IMHO.
Twostep
Re:Comments/suggestions from the other side (Score:1)
The success of your (ad)venture depends a lot on how well documented is your project. If you have full API specifications, clear and detailed Requirements, Statement of Work, etc., you can expect a sucessful project. And of course, this is true of any project (in-house, outsourced, OSS, etc.).
I'm sure there are good companies and bad companies. You can get a sense of the company's performance almost from the first meeting you have with them, and detect any problem from the start. Look for a technical interview with the people that'll do the work, so that you know they know what they're talking about. In the meeting you may also be able to discern if you will have any trouble with language barriers.
Shameless Plug:
The company I work for is established in Mexico, and has offices in California, so we share a 'normal' timezone (CDT), and are subject to US regulations. We've been working with several US companies and so far the response has been favorable.
Is your project late? (Score:1)
Re:programming is understanding... (Score:1)
Outsourcing, though, is a whole different thing.
Another bad experience.... (Score:1)
The biggest problem we ran into was that everything had to be spelled out in the utmost detail. The spec was several hundred pages, and even then they twisted things around and did things in complex ways, seemingly just because the spec didn't say that they couldn't. Of course every change or clarification to the spec had to be approved by managers and accountants on both ends, and resulted in charges more than the original contract.
If you can come up with a design document that has EVERY detail spelled out, and nothing in the system is unknown and nothing will change, then you might have a chance. Otherwise - you are in for one heck of a ride. Of course any software developer that has much experience will tell you that every system has changing requirements as it is being developed. So, you are pretty much screwed.
One word... (Score:1)
SAME HERE!!! Often easier to code than spec... (Score:1)
The time spent reworking the results for all the unhandled error paths, ect. eats up all the time I theoritically saved by outsourcing.
I must repeat the disclaimer though, I have found that if the spec already exists (RFC's w/ test vectors, ect.) than it can work fine.
I would second the comment that this should be left to black box items, never design issues or anything that a room full of interns couldn't handle.
Re:Can of Worms (Score:1)
I've been on too many disasterous projects that didn't work that way.
Outsourcing Coding (Score:1)
Some things that can help
- project will work best if the nature of the work is that requirements are clearly defined up front and it is easy to determine if they have succeeded.
- need to have *frequent* clearly defined deliverables ie weekly. Otherwise you will have no idea how they are going and you will find the project will suddenly slip months in one day.
- require proof of testing. Otherwise they will not test it.
- regular on site visits. You can initiate these at the start of the project, or later on when things go off the rails, as you prefer. There is no substitute for seeing the atmosphere at their place. It's best to have someone there all the time. That way they get used to having you there and you find out what's really going on.
You cannot outsource responsibility. You still have to manage the whole process very tightly. We do design reviews - no coding allowed before the design is approved, and we do code reviews by phone to enforce coding standards and documentation standards.
Good luck.
an example of what not to do (Score:1)
Here were the main problems:
- The communication overhead was huge. Most people on the team probably averaged about 2 hours everyday writing email to the overseas group.
- There were constant misunderstandings. It is very difficult to communicate effectively only by email.
- There were language difficulties. The native language of the overseas programmers was Spanish. Some of them didn't speak English at all.
The project ran over time, and the end result was a user interface that we couldn't use. It didn't integrate with our code, it didn't do what it was supposed to do and the code was commented in Spanish.I'm certainly not saying it can't work. But the project needs to be very effectively organised. This is what I think are the key points for it to work (maybe):
Careful on lowball time estimates (Score:1)
I would be a little leery (Score:1)
I am sure that the consulting firm will not dump every programmer they have onto your project. It will be put in a queue, and picked up at a later date. There will have to be at least some man-power designated to work with the consultants.
You always have to consider the learning curve factor, but in this situation you should have a general overview of how the app works (or should work). It depends on how well it is documented...which programmers generally aren't good at.
From the horse's mouth (Score:1)
All this said, if you do your homework and are prepared to invest significantly in the effort it can be well worth it.
Outsourcing experiences... (Score:1)
So me and another developer are transferred from Australia to Hong Kong. Over our objections, a lot of asset development is outsourced to China and India. Things did not go well.
Everything we received from the teams in China and India were consistently of such poor quality, much of it had to be redone locally. A collossal waste of time and money.
For outsourcing to work, you must have talented groups and exceptional communication between them. Too often, unfortunately, Bean Counters are unable to get a grasp on those basic concepts.
Re:Good Software Engineering (Score:1)
I don't disagree that code quality and project quality can be good with outsourcers, I've seen it from many a co-worker who went into consulting.
But what I also see a lot of with 3rd party consultants time and time again: rat's nest.
But, I'm just reiterating the past 30 posts. I just want the name of your outsourcer!
-Chris
Re:As with everything it depends (Score:2)
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
Re:Good Software Engineering (Score:2)
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
Types of projects (Score:2)
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
Re:Problems (Score:2)
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.
Success stories (Score:2)
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.
Re:Problems (Score:2)
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!
Re:Don't do (Score:2)
OTOH, I've also been hired to augment/port projects produced this way, too. Jobs like that help balance your karma out.
Outsourcing problems. (Score:2)
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.
Definitely send people over! (Score:2)
(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.
bad experiences (Score:2)
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".
Re:Laws and Languages (Score:2)
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).
Sounds like commercial software (Score:2)
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.
Twinkletoes (Score:2)
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.
when they are done (Score:2)
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!
If you want something done right... (Score:2)
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.
Re:It's no good (Score:2)
-B
My Experience (Score:2)
One, good, simple, deciding question (Score:2)
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.
Re:International Outsourcing - a Provider's view (Score:2)
Comments/suggestions from the other side (Score:2)
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.
Re:Russian programmers (Score:2)
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
Re:Problems (Score:2)
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.
Isn't 90% of coding maintance? (Score:2)
Re:Black Boxing - YES (Score:2)
Been there, done that (Score:2)
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
My experience: (Score:2)
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
RE: What Pitfalls Exist When Outsourcing Code? (Score:2)
Legal Stuff In Outsourcing Programming Overseas (Score:2)
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
A very important issue here... (Score:2)
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.
Wow.... my anti-situation to a 'T'... =) (Score:2)
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 [screwdriver.net], 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
Re:Laws and Languages (Score:2)
Keep tabs (Score:2)
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.
why not (Score:2)
Let me think (Score:2)
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.
Laws and Languages (Score:2)
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!
Re:Lots of things (Score:2)
Re:Lots of things (Score:2)
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.
Outsource overseas works well (if you do this) (Score:2)
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.
When they don't have to support it, it'll suck. (Score:3)
It's no good (Score:3)
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 (Score:3)
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 (Score:3)
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 (Score:3)
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... (Score:3)
- 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 (Score:3)
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 (Score:3)
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 (Score:3)
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 (Score:3)
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.
Russian programmers (Score:3)
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 (Score:3)
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 (Score:4)
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 (Score:4)
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 (Score:4)
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
As with everything it depends (Score:4)
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 (Score:5)
There are dozens of other things to a development cycle than just oursourcing 'certain problems'...
Several related experiences (Score:5)
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
Send someone over (Score:5)
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 (Score:5)
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.