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?"
...is fresh in my mind. That's because I'm cleaning up from it at the moment.
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.
I concur with your analysis. My company does this also and they have some success and some failure at it. The biggest problem we have had is with communication. The time zone limits time for communication to either 8-9 am est or 11pm-midnight est. Also, because the phone line is so poor, it is like using a walkie-talkie - one person at a time, over. Because of this, we resort to irc. The data connection to here gets dropped at least one day a week (Which means we pay them even though they don't work).
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.
having had a lot of experience in this department on the sharp end, i would say generally - avoid. there are areas where this can work (well-specified applications built entirely on top of your core APIs and not integrated, jobs which would be scriptable if Perl had an extra 25 IQ points), but there are also areas to avoid (core code, defining APIs, important things, stuff that *YOU* will get to maintain).
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]
You really should avoid generalizations like this. Indian programmers are just like any group of people, there's a wide range of skills. Personally, I've worked with some extraordinary people in India and then I've worked with idiots Indians as well.
I am currently in the middle of a project that is outsourcing. To give you some background (donning flame suit), I work for a consulting firm that has been hired by a fortune 100 company to manage the long term development of one of their key systems. The project has gone from a mix of about 50% consultant to 50% in-house staff to a mix of 47% consultant to 50% off shore staff with the in-house staff making up the remaining 3%.
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!
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.
Of course, with proper management, you can help to avoid a lot of these issues. Just pay attention - and be careful!
Crack-smoking moderators and losers behind the submission queue, let alone Jon Katz...
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)
"People will pay big bucks for the luxury of ignorance."
We had some contractors in New Delhi that were working for us, and we are located in a suburb of Minneapolis. The relative time offset between MSP and DEL is almost exactly 12 hours in the wintertime (we're 6 hours behind GMT, and they were 5.5 hours ahead), which made it very hard to communicate directly with the programmers in India (our office hours simply did not overlap).
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)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Tried oversea outsorcing. What we wanted was a solution in C++ written to conform to our specs, complete with UML notations and a spec that had been polished for two months. All they had to do was look at the documentation and write the classes according to the specification. The result? A C-based solution that was slow, poorly documented and generally an incredible pile of crap code.
No more american companies writing my code.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
This is going OT a bit, but higher level languages ARE a lot more productive than lower level ones. Of course, there are drawbacks as well, usually in performance terms, but programmer time is usually more important than execution time.
no taxation without representation!
We're successful. We take on custom jobs (Java: Servlets and EJB mostly) and do much of the design and management here and get most of the work done in VietNam.
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.
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.
-- Solaris Central - http://w
There is not only the concern of Brooks' Law, but also competence for the work requested. It is important to consider the level of work you will be asking of the overseas group vs. their actual skills. Are you providing gorily detailed project specifications or just a set of general requirements?
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.
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 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 MUCH cheaper maintenance and support contracts. And for that money you can have one or two drivers developed every year too! Roger.
At my current company, we outsourced the task of making a high-level API for our hardware. For what we wanted, this was a good thing - provided you do proper prep work.
...)
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
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..
-- these are only opinions and they might not be mine.
This reminds me of most anything, take mechanics for instance. You take your car to the mechanic, and you get it back with grease on the seats and steering wheel, a scratch on the front bumper and the radio tuned to a different station.
Nobody cares as much about your stuff as you.
I'm project manager of outsource company and lead a team of 6 perl developers. We have completed bunch of projects - different size and duration. We have failed project - and sometime it was our fault. But now I have some simple rules that allow me to avoid that:
- 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.
Not good for quality, but a very honorable thing to do.
-- Tov Are Jacobsen
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.
-- Tov Are Jacobsen
Smoking Joe, didn't I see you post somewhere else that your company makes software FOR INDIA?
That's kind of an important detail, doncha think?
Save the whales. Feed the hungry. Free the mallocs.
Isn't this what Waterloo CS students are for? Learn fast and come cheap. Check it out here.
DataSquid.net, a little about me.
Well, Use a CMM Certified company that is on a level of 3 or above. Make sure the company uses staged delivery model, and have like 4 stages. If the first stage is late. alert! If the second stage is late. MAJOR ALERT! now, if they are just a week or few late, that is okay, but if major late. Cancel and bail
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
-----------
"You can't shake the Devil's hand and say you're only kidding."
My problem isn't with their qualifications as much as it is communication. This may be cliche, but it seems a lot of stuff gets lost or confused in the translation. Plus, with my company, there are continuous change requests during the project. These complicate the issues. I don't doubt their skills. I've seen them do impressive work. I just have seen a lot of negatives on outsourcing some of our major projects overseas that caused them to be less then desirable and late. Not the coders fault really. It is more of a communication and distance problem. Not really sure there is a good way to clear that one.
I work for a company that had outsourced all the technical aspects of our products to a consulting company. I was hired to help bring the software in-house, after the company was not too pleased with the large numbers of bugs in the software. When we finally starting working with the software, we found out that it was filled with all sorts of hacks, poorly documented, and some of the code had even been copied and pasted from magazines and sample code found on the web. The code was not well documented, buggy and was nearly impossible to add new features to. That was almost a year ago, and since then, we have basically rewritten all the code they wrote for us.
In-house is always the way to go, IMHO.
Twostep
There are 10 different types of people in this world... those who understand binary, and those who don't.
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.
Signatures are supposed to be funny?
You refer to Brook's law... Is your project late? If so, then your project will get later by adding the coders... If it's not, then add the coders... If you hold Brook's law to any project then one person would have to write everything!
-- A hundred thousand lemmings can't be wrong!
I work with a lot of foreign programmers. While learning slang helps, I don't think it's a requirement. Knowing standard English is sufficient, as long as both sides work at building a rapport.
Outsourcing, though, is a whole different thing.
Stephen Molitor steve_molitor@yahoo.com
My worst project experience was with a contract company just down the street. I wouldn't want to think what it would be if they were half-way around the globe.
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.
Elbonia.
I've found that unless the task is extrememly simple, or an existing specification exists that covers every aspect of the project to the most minute implementation and testing detail, it is generally faster to do it myself then to spec the problem to the point the result is usable.
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.
Hell yeah! The first rule of success on any project is that one person gets the say-so. If the CEO wants it done different, then he damn-well has to go tell that one person to say so before anything gets done.
I've been on too many disasterous projects that didn't work that way.
The cake is a pie
In any deal like this, you need to allow for a lot more management overhead than with an in house project.
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.
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):
One thing I've heard many times is that an overseas company will give a very lowball time estimate, like say, 40 hours, when the project will really take 80 hours. Then, when the workers don't meet the timeline, they take it as a personal failure, and work double time. That's not good for quality.
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.
All this said, if you do your homework and are prepared to invest significantly in the effort it can be well worth it.
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.
So if these outsourcers are so good, who are they? I figured you might like to share with the world, make them some money maybe, indebt them to you?!
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
Outsource development means that once the code is done, the developer moves on and doesn't have to worry about it. They don't care if they do a crappy job and future product versions go to someone else, because the market for outsourced programming is still huge, and they can always get more clients.
We have such a problem here where I work. An app was outsourced, and the code was so bad that several of our NT admins (Yes, bad code on NT, even worse! Seeing it was what made me decide to walk away from Windows forever so I never have to deal with something like that on Wintel.) ended up getting devoted to working with the people brought in to fix the mess. Those poor admins spent months with their pagers and cel-phones going off endlessly day and night, and one of them just stopped coming in one day.
If your company tries this, tell them no. If they do it anyway, RUN LIKE HELL!
Hell, I get those same things when I do the job myself!
Hello little man. I will destroy you!
I've been on both ends of the outsourcing deal, and have the following observations ....
1. No-one I've ever spoken to has ever ended up happy with the results of outsourcing, the usual gripes are poor quality, loss of control over the project, and lack of ongoing support.
2. When working for an outsourcing company, they would make an initial bid of about 75% of their estimated cost, thus ensuring they'd win the contract. Once work had commenced, they'd look for every ambiguity or oversight in the specs, and charge big $$$ for them as "variations" to the project. There are always changes to any non-trivial project spec. The client usually ended up paying at least twice the original quote.
The bottom line is, if you out-source a project, the out-sourcing company will end up with all the expertice, while you are stuck with a system you can't possibly maintain without them. They own you, you'll never be able to get rid of them, and the ongoing cost will be far more than it would have cost you to do it yourself.
Quidquid Latine dictum sit, altum videtur (anything said in Latin sounds important)
The biggest problem I've experienced with outsourcing code is one of incentives: people who aren't part of your organization invariably have less of an interest in doing things correctly than those who are part of it. Every time we've used contractors/consultants, we've gotten kludge after kludge, without much documentation and thought toward architecture.
I'm not saying that all outsiders are like this, just all the ones I've had to deal with.
There's also an issue with expertise: many contractors/outsourcees have a preferred way of coding and architecting things, and will invariably push you to go with their way. Sometimes you can get away with that, but usually you run into problems.
I once worked for an investment bank that had originally outsourced a big portion of their development to consultants who insisted on using Sybase PowerDynamo with IIS and Sybase SQL Server, all running on NT. That's what they knew, so that's what was chosen. Everything was hunky-dory until they took a certain Linux-related company (which shall remain nameless) public and had to scale to meet a greatly increased server load. We ended up having to switch architecture 3 weeks before launch and basically re-writing the code the consultants had written. Ultimately, we ditched the hokey Sybase architecture in favor of Java servlets.
"You done taken a wrong turn."
-Bill McKinney, in Deliverance
we (a small german company) once outsourced some stuff to romania. There was a strict task they had to implement, but compared to what we do in-house the failed horribly: - first problem was the language: they spoke a bad german and a bad english, so the best communication was between my boss and them, boss speaking a horrible english :)
- although we let them use their language of choice they did it in VisualC++, using DAO. They only cared about doing their job, not optimizing the code (like using indices for the database). Therefore the application got really big (due to the DAO installation) and slow (due to suboptimal database design)
- although the resulting code was good documented it is hard to change, because they did not think much about program maintanance (e.g. design it to be open for further development). No wonder, of course they hope, that if we need changes we need to hire them again
- they took twice the time they planned
On the other hand we used the same company for small work (stupid editing of word files, they could invent macros to speed up the work) and it went fine.
I guess it highly depends on what kind of job you have. For high skilled work I would rather use local programmers (so that I can see them face to face sometimes, that makes communication much easier) and if they are not available one could try a remote company. The most important thing I consider is a good communication, e.g. no language barriers.
If you are going for remote companies just to save money I would guess that you get what you deserve. Good quality isn't cheap.
This is good to hear. I am also a comp. sci. student and really take software engineering, configuration management, and the like very seriously. Most of the industry horror stories I have heard have involved a "core developer" who kept the design plan close to his chest and left for a new job without leaving proper documentation behind (there are many other stories but the common thread is always "no documentation and someone/people left").
I have always thought that coding should be the easy part of the project. Fixing a design requires an eraser---fixing a partially completed project involves time, money, and hard work...
When I finally leave school I am hoping to find a place to work that employs these design techniques. I know they are out there! :) I even use this approach when tackling assignments and other small projects. Does anyone else do this or am I a freak?
--8<--
--8<--
Don't get me wrong... I've seen plenty of places that DON'T use it. Small wonder most software projects are over budget and late. This is why I am so sure I want to work somewhere that does "do things right" (in my opinion, anyway).
--8<--
--8<--
The time it took us to right the specs, we could have coded the site ourselves.
Ummm ... I know that some projects don't write specs, but not having a written spec. is just asking for a disater. Because, without a written spec, its almost impossible for you to say you didn't get what you wanted. Without a spec. you let them say that ever fault that you want fixed is a change ... even if its something you originally wanted.
---
---
"Don't anthropomorphize computers. They hate that."
I've outsourced a great deal of work; I worked for a software company that worked along the lines of a publisher. My job involved co-ordinating many outsourced projects. Developer by background. Here's a list of some important things to remember.
1. Cultural issues. The person managing has to have a very clear understanding of cultural sensitivities. Ideally they will have travelled widely and lived in several countries so that they understand why and how other people behave. Having a grip on this is probably the most important problem to solve because it alters how you behave.
2. Don't bother for small assignments. The overhead of managing is larger than it is worth. Only outsource large developments where the cost savings can be huge. Plan on having a long-term relationship.
3. Find developers who are in the top 5%. Do not work with anyone who is not excellent. You will be wasting your time and money.
4. Be prepared to devote one person full-time to managing the project. You will only get what you want with clear specification. But as we all know initial specifications are never right. You overcome the problem with continuous feedback. Talk several times a day.
5. Be prepared to visit quarterly for a week or two.
6. Pay on goals achieved and not time worked. Be flexible on the first few payments - you need to set up a metric so that you are paying regularly for goals achieved. Always always always budget for slippage. Despite paying on goals remember that people need to eat. If they fail to hit a goal you need a system worked out to make sure that you are not starving them of income. You do not have to tell them about the system though. You do not want them to have to take on other work because your project will come 2nd place.
7. Try very hard to set the mood. When you have in-house developers you can respond instantly to despondency. It's so much harder when people are far away. Remember that people are people - do the things that you would do if they were sitting next to you. Have the company pay for the team to go to dinner. Arrange for flowers. Judging the mood is another reason for point 1.
8. Don't micro-manage. For instance, let them take all the architectural design decisions. But do keep a constant check on the state of things. Ask questions about the internals.
9. Be prepared to bring in outside expertise. Make sure that the team understands this and understands that this is not any sort of insult. For instance - user interfaces have quite deep cultural influences. If your UI is designed by someone without an understanding of the culture it is designed for then the final item is likely to be unappealing. For instance - imagine developing a mail program. If you put a US style mailbox on a button then it will not be recognised in Europe. If you use Indian colour mixes Westerners may find the interface garish. If you the interface involves scenes then the scenes may be alien - a program teaching kids about money set in the gun fighting Old West will have zero appeal to teachers in Germany. Especially when the key character (a talking gunfighter dollar sign) appears. You may have guessed that these are real world examples.
10. Be prepared to work odd hours. Asynchronous communication slows things doooooooowwwwwwwwwwwnnnnnn.
11. Empathise.
12. Watch the budget like a snake watching a mouse. When you outsource you give up direct controls - but you do still control money flow.
13. Be prepared to kill the project. Have clauses in the contract that allow escape routes. Have your fallback position planned. The first project with a new team is the riskiest.
14. Have a good contract. Make sure that you explain the contract in clear normal language and not legalese. Double check that they understand what they are agreeing to do. Triple check. Spend more time than you have to. Develop trust. Make very sure that everyone understands what belongs to who when and what the deliverables are. And what belongs to who if things go badly. Then forget the contract - it pretty worthless as a piece of paper. If things go badly you can pretty much kiss your investment goodbye - trying to sue across borders is not worth your time, effort, money. The value of spending time on the contract is that you make sure that everyone knows what they are supposed to do. Be prepared to negotiate contract addendums as the project continues. Nothing ever matches plans. Ever. You will need to change the terms. Be prepared to be flexible.
15. If it's possible test the people concerned with a small project before diving in the deep end. Remember: the first project is the riskiest.
If you need help - I do consultancy.
Jeff Veit
http://www.tanasity.com/ - Tanasity develops software and net applications
http://www.tangledtime.com/ - New! Discussion about the net, software and business - come and contribute
Tel: +44 (0)1223 721513
Well I work for such a company too - only I'm one of the guys overseas to whom such things are outsourced.
I think you are bigot to say what you are saying - in fact I could say the same thing in reverse.
We frequently have to fix screw ups for which American companies are responsible.
MbrIts not where a company is that determines the quality of its workers - and our education system is the equal or better of the underfunded education mess you seem to have in the states
Don't believe anyone here when they say you should or that you should not go. This is one of those choices that must be made by yourself for yourself. Before you make a choice about post secondary education go for a year and see if you like it. See if it is all that the advocates of university/college say it is. "Don't knock it until you try it" is what i always say. Go to the best university you can afford... it will give you a better gauge as to how suitable PSE is for you.
If however you find that after the first year you decide that it really isn't for you, it IS ok for you to decide to charge out on your own. Don't let anyone here (or in your life) tell you that "you will never become anyone great if you don't have a university degree". University is but another means to an end... not an end unto itself. There are many means out there in this world to learn and to grow and a Unversity is not the only one.
However having said that, the responsibility to enrich yourself and and to learn and grow rests squarely on your shoulders. Learn many things... not just programming and computer related things (although they are important and will take up much of your time). Keep up on current events, think critically about things, argue and debate, and read some of the great books of our time (you might even like a few). In University it is in anticipation of the next exam that motivates you to learn and remember things (even for a short while :)... you will need to motivate yourself to do this instead.
All the things i mentioned above are possible... if your are the type that natually questions everything and chases after answers then there is probably very little that you couldn't learn on your own that a University would have. Know this however: Not being in University is tougher than being in there since self motivation plays a much larger role... but it will be worth it in the end.
I got out of university after around a year because it was not for me... i haven't regretted my decision. In a time of my own choosing i might even decide to go back... but not a second before (and not because someone said i won't get paid a dime more until i get a degree).
Ceres
I know of one large Australian company who hired a bunch of Lithuanians (via a US contracting company), and apart from the usual dramas of having 4 different groups of contractors working on the same project and hating each other, they were the ones who were getting things done (as opposed to just producing lots of management-style documentation). I would hazard to say that it was the contracting firm in California that was getting the $$$ though; these Lithuanian guys were living onsite for a while I believe. I think outsourcing sucks generally. It shows a company has no confidence in its own people, and not wanting them to learn and develop their skills seems a sign of a company that is managed by fascist pricks. Ones who get sucked in by guys in suits charging $500 an hour to tell them things like "the sky is up".
We threw a linux port of some Solaris stuff to a bunch of Russians living in Taiwan (or was it Singapore?) Not only did the code come back buggy as hell, but to my knowledge, they kept it for their own use. Oh, and they had the gall to call us in the tech support department and complain about bugs that they'd written.
Vintage computer games and RPG books available. Email me if you're interested.
We have done a fair amount of it. In the end, the code we get is always horrid, but thats ok sometimes. When we have 600 reports to bang out, and none are all to complex, its ok if its ugly. If one doesn't work, just redo it. For TRULY grunt work, meaning that the above outcome is acceptable, go for it. Except for situations where we have had someone who worked for us in the past, running the project at the other site, you just can't get anything better.
I am doing tech-managing of some programers that are porting/rewriting some out-sourced code right now. I believe "Caveat emptor" says it all.
Let the buyer beware!
Shane
I was at a company that did exactly what your companey is planning to do, with disasterous results
There code was sloppy(at best). It was clear to us that the coders that they "threw at it" where clueless.
There company said the had coders with years of experience, and if that was true, that must have just been stupid. There's nothing like 20 levels of indirection to really make things fly!
The interface was more then uglt, it was alien.
Then when they delivered the code "right on time" it went back to them 3 times because it did not work.
In the end, we ended up writing it ourselves.
I say do not out source! if you do outsource, do you have a reasonable way to take a recource when the code isn't up to spec?
hat can be difficult with a lot of the hack and burn companies.
What assurances(if any) do the coders at your company have that when it fails, they won't be tasked to do it in an unreasonable time?
How fast can the out sourcing company cope with spec changes?
Can you contact the out sourcing company during your regular working hours? or will you end up playing phone tag, while they jack up the bill?
Will they have version control? If so will you be able to access it anytime to check there ACTUAL progress vs. there reported progress?
Do they have references from other companies you can contact?(perferably contact the coders who had to deal with the code when it was brought back in house)
I have the same beef with most 3rd party software solutions. over and over again I see some company promise "fast integrated solution" that just don't work. We recently brought into our company a product to speed up web deployment and use as a server.Its called silver stream. It was suppose to allow us to deploy a web site 'fast'. well I doesn't work as promised, we had to bring in 2 "specialists"(at addition al costs), and management refuses to listen to the software professionals that they pay when they say it would be quicker to dump silver stream then it would to continualy 'mesage' it to do the simpliest java script tasks. This is typical management ignorance of what goes on in the coding process. The see that it will be cheaper on paper, and have the attitude that all coders do is type all day, so they figure they should out soure the code.
The Kruger Dunning explains most post on
Working with, say, programmers in India, you have several issues. Language is very different, as is the timezone. Indian programmers are not generally as good at producing code, nor can you expect them to put in overtime. You will have to go down and visit them from time to time. And their infrastructure is severely lacking at the moment... share ONE dial-up connection per office and even that will be down rather a lot.
There are a lot of challenges. You spend a lot more time managing them than you would European or American programmers. They are absolutely not capable of being dropped in to your project, despite claims to the contrary.
But if you have a year or so to ramp them up, you may well find excellent return on your investment. There are some good programmers down there and even with the cost of extra management (and extra design), you may win out in the long-term.
Trust me. Do not consider this a worth-while short-term investment. Because it does not work in the short-term.
Oceania has always been at war with Eastasia.
Alternate programming languages being more productive is by no means a myth. I've worked with (pretty much) the same group of people on two projects in a row: the first in C++, the second in Java.
While the C++ version was certainly the more memory and computation efficient of the two, these benefits paled compared to the improvement in development speed and code quality we acheived by switching to Java. Since then I've moved to another company where we use almost all Java (with little bits of other languages where Java is bad) and we're about to do things that we wouldn't dream of doing in C++, let alone C (yes, I've worked in C for a couple years as well, so I know whereof I speak). Before that first Java project, I thought it was mostly a toy language. Now I'm a believer, and looking for jobs I look for Java.
Java does use more resources to run, but in my experience less to program. Of course, programmer quality probably effects what sort of development speedup you can get - a bad programmer is slow in any language - but...
I've seen a company outsource work overseas and it's been sort of a disaster for them. The outsourcing shop wants to just turn over the code to the original company, no support or anything. Unless it's real simple code, the support will cost more than originally writing it.
If it were my company, I wouldn't bother outsourcing (overseas or with a U.S. shop, even one of the "big five"). It'll cost more in the long run, if the company survives.
Get some decent coders and keep them. It's not that hard. Just listen to them.
They were given the task of converting all the strings in a piece of code to wide characters, because we didn't think this would need too much specification. Amittedly there was a communication problem (they examined every file manually when they should have been using grep), but when they did change code it often would not even compile afterwards, it would contain memory leaks, or would segment. It took up a lot of our time sorting it out. It also took them so long that they did not finish the job before their contract expired (this was supposed to just be the first job of many).
We heard from programmers at the other company the same sort of thing was happening there. So imaging our suprise when both companies declared the out sourcing projects to be a great success.
Our director who was responsible for taking them on quickly moved on to bigger and better pastures new, but the company still recommends the Indian company involved. I was watching News Night on the BBC this week and this Indian company came up as one of the great success stories in out-sourcing, infact they were highly recommended.
My company has had moderate success. We contract out routine enhancements to some existing systems. These are large databases with a lot of inputs coming from outside our company. Whenever we form a new partnership, the outside data has to be massaged to fit into our way of doing things.
The contractors do well at this because they always have examples of similar code in front of them. Often it's just a matter of snapping together some of the same reusable components in a different order.
Requirements analysis and integration testing is always done onsite. The contractors are only responsible for coding, unit testing, and detail design documentation.
Email, conference calls, status tracking tools are all a must. Seeing each other in person now and then helps too, especially for training.
Sure, outsourcers will take longer to do the job than you would. But they will free up time for you to do things that contractors couldn't do at all.
Quis metamoderunt ipses metamoderatores?
It took two of us several weeks to put the code in a runnable state. Let the buyer beware, you get what you pay for.
I think it's time that management type realize that coding is difficult and that 'grunts' and inexperienced people can't do the job an old pro can.
Anyway. I think it's just the U.S. looking for a way to sweat-shop IT as well as every other kind of labor that they have "outsourced". The problem is that you CANNOT have sweat-shop labor with knowledge workers. It just doesn't work. The best people leave for better opportunities, and since the best opportunities (most $$$) are in the U.S., who do you think is coding your outsourced project? HMMMM? That's right, the chaff. BTW, I'm currently involved in a project involving outsourcing to Pakistan. It's a trainwreck-in-progress, let me tell you. Not sure management knows it yet, but hey, I'm just a consultant there, so no one would listen to me anyway....
Why not just outsource your code to an infinite number of moneys? They could write it for you instantaneously, and you wouldn't even have to give them specs. :-)
Hey, it's not like I'm the only one who ever thought of this...
OtakuBooty.com: Smart, funny, sexy nerds.
My company recently outsourced code for a seemingly small and somewhat simple project. The folks we worked with on it barely knew what they were coding. They literally lied to us about knowing enough to do it right.
We just fired them and now there's only two of us stuck rewriting a ton of the bad code. I had to clean up all the HTML and Javascript on every page. The PHP was half-finished, leaving us with a mess, and the MySql database is unorganized and nonsensical.
Don't do it!
--
Marv! They killed Reagan!
"Marv! They killed Reagan!" - Jimmy Carter
Whenever coding is outsourced, you are basically relegating the look and feel of the underlying code to the standards and development style of the person or person(s) you are outsourcing too. If your company has coding standards, those probably will have to be sacrificed. Secondly, there's no guarantee that any code will be documented and if it is, documented well. Thirdly, you just never know whether the same quality will be there. I consider quite important to review those three things about the standards the outsourced programmers have regarding their code. While it might save money on the front end, down the line the cost in service to debug, QA, and support another's work may not be worth it.
Can what is formed say to that who formed it, "Why have you made me thus?"
My experience has been that the consultants come in, talk big, have alot of meetings , make lots of promises, throw out some code and leave. Then the in house folks have to go back and clean up the mess.
http://www.windmeadow.com/
One thing I think you should keep in mind when outsourcing is that your team will not be as connected with them in terms of communication. Therefore, it will take a lot of work to keep things integrated, and you will need to spend time just collaborating. You may find that unless there is an AWFUL lot of grunt work, the time spent won't have been worth it. I recently went through a similar situation myself with a cloning process for computers: in the end (ended up being due to someone else's bug, but thats not the point - but may be relevant in that it's easier to fix your own bug then someone else's) it probably would have been faster for me to have done each computer individually myself - don't get me wrong, cloning was great (and for the future), but for this project it would have been faster for me to do without it (basically, keep in mind the added overhead and frustration from outsourcing - something might not fit your style, or a function might not work well (optimized?) for your application of it).
SSL Certificate
Just another reason to go open source...
Life...
ourpla.net is your planet
There are at least three:
Unless the API is very well defined, having software developed at more than one site will increase the costs of development. The CoCoMo II model (Boehm et al.) treats the costs of software development as increasing as the organizations become more physically distributed. I can confirm this happens.
Security is much harder to ensure if software is outsourced internationally. Basically, if it turns out that someone has inserted a backdoor, it's harder to discover that it has happened and it's harder to do anything about it (legally).
Software engineering quality. If you want high quality software, you have to pay for the corresponding education/training.
I hope that helps.
Everyone seems be to assuming a lot of things about who is outsourcing to whom. Stop for a minute and think about it! Try to make comments that are more useful in general.
Since mmmmbeer didn't say, why is everyone assuming mmmmbeer's company is US based? In fact, why assume anything?
Who do you think lives overseas - me or you?
Perhaps the single most valuable tip... require code reviews and conduct them jointly (at least the first few, and occasionally thereafter). All sorts of reasons to do this.
* It will give you early warning if your design document is inadequate.
* It will help with cross-training (bring contractors up to speed, and help internal staff learn new technology).
* You can make sure they are following your internal standards (like documentation).
* It will also give you an idea of the competence the programmers and organization.
There is almost always some type of learning curve. Make sure you account for the internal support time.
Your company will "loose" knowledge by outsourcing. If this knowledge is key to your business, you probably don't want to out-source it. If you have to out-source (for instance you don't have internal resources who can do that), look at a formal training relationship. Note that I've often see training attempted, but it has a high failure rate.
Out-sourcing usually means that you have to improve your documentation, so don't forget to account for the extra time if you don't normally do good documentation. If this is new technology, you probably won't know enough to have a good design upfront, so plan on doing the project in phases so you can correct and clarify issues with the original design document.
You need excellent acceptance criteria. Formalized test plans are best. They can be written either internally or externally, but must be jointly reviewed for completeness.
In summary, it can work if it is done carefully. The successful out-sourcing projects usually have the following characteristics (in my experience):
* Long term relationship with out-source firm
* Projects are not core business
* Projects are reviewed, weaknesses identified and corrected with next project. It takes continual work.
You obviously haven't seen the wages we get paid. My I humbly suggest doing a little research, like having a look at Jobnet
This - and other - links might give anyone thinking of outsourcing here an idea of how much it would cost. And you'll find people who are familiar with CMM, .jsp
technology etc at ridiculously low rates.
Australia is a bit like Southern California - beautiful beaches, wonderful weather, but beer is twice as strong and half the price. Wages are low, but prices are lower. Take SoCal, subtract the guns, the drugs, and the money.
Zoe Brain - Rocket Scientist
Be careful of communication barriers in (spoken) languages. Also, be sure to decide, review, and finalize all requirements prior to signing the deal. It never hurts to be very specific. Also, establish a rigid timeline and a payment schedule based on successful implementation of requirements. Best of luck!
main(){char I,l,O[]={'-',1-1,0,(1<<5)-1,0+'-',-10-1,-10,11-0,
The most important issue to deal with when outsourcing is to have a clear idea of whats required yourself - and then to convey the idea accurately to the outsourced people.
The biggest problem I've seen is that projects that are not clearly defined end up falling short of expectations. The Outsourced firm then takes advantage of the fact that out of scope works are charged at a very significantly higher rate. Then of course there's change managing those fixes.
I would say the second one.
Unfortunatelly Russia is a place where anyone with a lot of money (that would be you, an investor) will draw a lot of attention. And there would be a lot of people to try and get a share/all of it. With guns, etc...
Russia is not a safe place to be, so it is not even safe to come to Russia and try to oversee something. Mafia may even just get to the codeshop, take the money, and close it. And there is nothing you can do about it.
So a choice is to know people there who are involved in criminal activities - this is as common as a profession as any other, who would take care of that dark side of things.
This is just my two cents, I am not raving about the situation. I feel very sorry for them. Unfortunatelly I knew people who got damaged for even less kind of money.
http://dtum.livejournal.com
about the eye thing you should have a link to Aldous Huxley's book about his exp with it. Something like Learning to See
Australia is a good place to outsource code to. The standards & education are high (probably higher than the U.S), there are no language or law barriers, and the Australian dollar is only worth about 60 U.S cents so costs are about 40% lower than U.S. consulting. There is also not quite such a shortage of labour.
:)
You could also try Canada, but I think most of the good programmers have moved to the states to get paid more
"I have been around the world and found that only stupid people are breeding" -- Harvey Danger
Seriously, though, almost any time I have seen a company outsource anything delicate, or where the goal in question was not completely and totally generic (account collections, for example), the company runs into problems like:
The default Computer Science answer fits here, of course: "It depends."
It all depends on who you have and who you work with. If you can form a solid, comfortable relationship between the in-house experts and the outsource "grunts," they will be effective. They will still require some time from your people, and will take a little longer than the same number of your own staff, but with effort and a good attitude on both sides, the overall productivity will still be higher than without the outsource group.
That being said, if there is NOT a good relationship, the $h!+ will interface with the fan. Your people will be spending most of their time helping/reviewing/yelling at the outsource people, and will not end up having their time freed up to persue other work. Quality of work is more a question of the general expertise of the outsource group and their ability to understand your requirements than anything else.
If you feel you have a good relationship with an outsource group, it should work out. If you don't feel that, or you haven't found an outsource group to work with yet, think long and hard.
The Mythical Man Month doesn't really apply here, because you're probably looking at a similar (but separate) number of people on the project, not just adding X more people to the same set of tasks. Again, it's mostly a question of how well the outsource group can take over the work, balancing their productivity against the need to keep your people in the loop.
Hope that helps!
Xentax
You shouldn't verb words.
There are following outsourcing myths:
Outsourcing can help finish the project faster In fact yes and no. Actually any contract work is done faster than at-home development. This happens because contractor is interested in finishing his work in time and is more resistant to the pressure from future users or resellers of the product. One programming law says that the probability of corrections to the initial design is proportional to the time of development. Home developes more likely will incorporate changes and shift timeline, contractor will insist in next release of the product, which is better. On the other hand, code is code and it is impossible to write it faster.
Outsourcing will result in a bad product because they do not know our business realities Wrong. Taking average business person and average programmer, tell me - who is smarter ? Also if a foreign company takes the project, it is high chance that it is not their first one.
Outsourcing will result in bad documentation Maybe. It depends on you. Write it in a contract, and assign someone to check the result. Homegrown teams usually make no documentation at all.
Outsourcing will result in bad support. Can be so. Add training your personnel to the contract.
The financial part of the problem look like this: consultants who are working on your site costs the same, or even more than regular domestic contractors. Developers abroad costs much less.
The financial success of your enterprise depends on how the work can be distributed between these groups.
We have just recently discovered some of the pitfalls of this in the division of the company I work for. We outsourced the coding of a new embedded product to an overseas company who were skilled in this particular type of product. Some of the problems we found with doing this were: It took much longer (they actually stopped working on this product as they wen't well over budget and demanded more money from us to complete it (And no, I have no idea why the contract we had with them allowed this to happen)) In the interests of time much of their code was ported to C from the ASM of one of ou existing products which meant existing bad practices etc were carried over. We had to send a couple of our guys over there to try to learn how to use some of the development tools they had used so that we can support the product. They decided to use a development tool which was very expensive and therefore only one was purchased (meaning we couldn't both work on the product at the same time) Their test plan and cases left a LOT to be desired, they basicly only tested the couple new features they had included and didn't even intend to fully system test the product. This is just one experience we have had tho and I am sure it would be different for each case... the one thing I can say tho is make sure you have VERY good requirement specs (right down to every trivial little detail) and also a good legal contract with the company (make sure they can't just suddenly decide their going over budget and won't do any more work until you give them more money)
We have had both good and bad experiences outsourcing development work. Outsourced developers are terrific when you need to ramp up quickly or want to cut costs by moving development off shore where coders aren't so difficult to find and keep, and they aren't so expensive, but don't think you can simply pass off a spec to the contractor and wait for the completed application to be delivered. We have found that this is just asking for trouble. If you plan on bringing on outsourced developers, plan that it is going to be a long term relationship. You will need to closely manage the project and monitor progress often. Standards of quality are very subjective and differ in various parts of the world. Alway get the source code for each build and don't pay for everything up front. Make payments as milestones are reached. Also, plan for long term support of the project at the beginning of the project, not the end you will always need continuing support, and it is better to negociate terms before the project begins rather than after the project is completed. Also, if you use off shore developers, make sure it is a local company with an off shore office so that all contracts are local and you can pay locally. Enforcing international contracts and moving currency accross borders is often more trouble than it is worth.
If the portion that you're outsourcing can be neatly separated from the rest of the system, then out-sourcing can be a huge advantage. All you need then are the well documented API's and instructions, and it's like buying an off-the-shelf component.
This of course, assumes that the company you're outsourcing to is competant. Meaning that as with anything, they should be thoroughly checked out prior to signing the contract.
However, the statement that you can do it better and faster in house bothers me. The compnay I work for sells software components. Our biggest source of competition is not other component vendors, but the attitude that we get from many developers that no matter how good are product may be, they can still do it better and faster. That's sounds strongly of an ego trip to me.
I mean, most software is not incredibly revolutionary. As a developer, I consider myself competant enough to build almost anything. But on the other hand, that's probably true of most other competant developers. Just because you CAN do it, doesn't mean that you NEED to do it, or that you SHOULD do it.
I can spell. I just can't type.
At the time, we did not know we were doing this competitively with an outside firm. While I doubt it would have changed our estimates, it might have directly effected our thinking.
Anyway, this outside firm came in with a time estimate of 3 months less time to product for 60% of our cost. Obviously, management decided to go for the out-sourcing. They started negotiating the contract, and let us know that we would not be expected to build a new product. Since that meant we would be in maintenance mode, we lost many of our good engineers.
A year later, they still did not have a signed contract with the other firm. (Had we been given the go-ahead, our estimated time to product was a year.) Management came back to us to ask what we could do. Well... Not much, we'd lost most of the qualified developers.
I left shortly thereafter. (I had stuck around that long to reach a pension-vesting date.) Last I heard, they had still not signed a contract, 12 years later.
Depending on what is being outsourced it can lead to real problems in the future. Nothing like hiding outdated procedures by getting someone else to do the job. "We're too busy to do it ourselves." May mean we don't know where to begin and have been burned trying similar efforts before.
Well, sir (or ma'am), I think you've just won the prize for most poorly-veiled racial slur.
Your vicious sweeping generalizations aside, my company employs many non-US programmers. Many of them are of Middle Eastern decent. We produce outstanding award-winning software and we stay profitable.
Perhaps I'm out of line, here, but I think you're just spreading anti-immigration FUD to preserve your overpaid position. How horrible it would be if your managers found it they could get software equal or better than yours from a bunch of "im'grants". And at half the cost, too. This must keep you up at night, AC.
If the lameness filter actually worked, would you even be reading this?
Gotta love it when someone references Operation: Mindcrime.
R-E-V-O-L-U-T-I-O-N
...I remember now.
If the lameness filter actually worked, would you even be reading this?
A project I still work for had an overseas business partner (in the UK). It worked out very well - they worked on a couple of relatively self-contained parts.
The biggest problem was communication - the timezone difference meant that conference calling was limited to a fairly small window. Also, the size of our build products (this is a big project) meant that it took them a while to FTP the latest build. However, transatlantic bandwidth has increased quite a bit since then.
Overall, it was a positive experience. Our business partner was doing more than just "grunt work" too. (Importantly, they had prior experience in what we were doing). It is unlikely that it was any cheaper than hiring a boatload more of people to do the work here (maybe more expensive) but they had the right experience and good people, and that's what made the difference...and they didn't have a learning curve to ascend.
Oolite: Elite-like game. For Mac, Linux and Windows
Sorry but these comments seem very shallow. Take India as the prime example. Most of the programmers have Comp Sci/Engineering qualifications followed by up to SIX MONTHS of professional training BEFORE being let near a project. Half the level 5 CMM companies in the world are based out of India and they tend to do an excellent job. This is based on personal experiences.
If I were you, I would have my company write all the code its self. If you start having someone else write the "Grunt Work" of your program, then unless you go over their code, taking more time than writing it yourself, you do not know what kind of weird interactions will take place. No matter how well documented the code is, there will be one or two workarounds, that will cause problems for your own programmers. Besides, when you write the code yourself, you are more in tune with the nuances of the code.
=================
Unix is very user friendly, it's just picky about who its friends are.
If the in-house programmers are up to snuff, there would be no reason for the MBAs to look at outsourcing. Maybe the in-house folks aren't performing as expected? The outsourcing of code is no different than outsourcing, say, steel fabrication. Companies do that when they think they will get a better deal from outside because the inside people don't produce because they are too busy having lunch, or sometimes because the costs of using in-house people has bloated because of internal bookkeeping problems or because the shop is filled with primadonnas that can't do the gruntwork. So go ahead. Outsource, but just recognize the management efforts still required to get a good product. Perhaps you should suggest outsourcing the accountng department, project management or senior management of the company. That's where *real* gains could be made. Or move off-shore, get some local hotshots working for you, and make a killing.
Many managers (Dilbert anyone?) perpetually forget about maintenace. If they are looking at outsourcing to begin with, it is almost always about cost (as in quality & documentation shall not interfere with getting the best price). Eventually it will be these very same managers that will also try to save money when it comes to maintenance.
Your company may be organized differently than ours. PM's in our organization report to the Director of Technical Development who reports to the CTO. The PM in question, while a nice guy, was not technical and was being asked his technical opinion by this company. He was way too far down the totem pole to be used as a second opinion. It was pretty clear to me that they did not want to take direction from the woman ultimately in charge of the project. If the CTO tells you to do something, you do it.
PM's are not CEO's. This company did not call the CEO for a second opinion. They called the only man they knew on the project, a Project Manager.
Agreed on both points-WebObjects rules and no Specs is usually a bad thing. Unfortunately, in this case the firm was hired with the knowledge that they would have original, working source code but no specs. (The site was live already just on another platform.) For myself, if someone told me take a site running PERL and make it act exactly the same using WebObjects, I could make it so without specs. That's just me.
We are a small group in a larger organization but we are WebObjects programmers, so yes we could have feasibly done it but at a cost to the other projects being managed.
Decisions were made at a higher level and we were stuck because the outsource decision had been made, agreements finalized and we just had to make it work.
I've had good success with outsourcing the coding... but I've also had bad. It really depends on what kind of promises have been made in the contract. Is it a fixed price contract for the entire job? Are there incentives for low bug rates? If you can get someone else to do the ugly stuff for you that nobody wants to deal with, I say go for it. Just make sure that it's management that makes the decision. Don't get sucked into it for your opinion - otherwise you might get sucked in to fix the mess.
I've been working the "Other Side of the Fence" for a few years now. We do mostly work for Japanese companies, who are happy to take advantage of the exchange rate differences to get cheaper labour. (Currently 41c to the US dollar) We support all our code - to the limit that the client Management is willing to pay. A lot of the time, once the project is signed off, that's the last we see of it. We've done grunt work before - and it's a grind. I don't enjoy poring over hundreds of xls sheets looking for y2k bugs any more than you do. Being in a different country doesn't change the meaning of boredom :)
Honestly, I don't think we would get any particular job done faster than an inhouse team with the same number of people. But we are cheaper by the hour, and we can put more people on a job. (sometimes - depends on the company)
The biggest problems we have are communication, and shifting sands. We've learned to ask a lot more questions about what the client really wants, and not to assume anything. But we can get a lot of emails sent between NZ and Japan in a day. It's important to have a liason who can get answers to our questions at the client's site.
On occassion, we've gone over budget, sure. The usual reason is that scope creep is an insidious beast. Tell me you don't get scope creep in in-house jobs, and I'll sign up tomorrow!
I like filling overseas contracts, I take pride in a job well done. If you're getting poor, unsupported code, then you're not using the right business.
There is a solution to the problem of ending up with the outsourcing company "owning" the expertise and the business leverage. Just hire more than one firm, and use open source methods to distribute the work between them and your own staff. You keep your options open.
Hi, I'm in Thailand. I'm doing development work for a US company. We have 25 developers here. We produce application software.
Here are some of my experiences as an outsourced developer:
Problems:
1. Vague specifications or frequently changed specs.
2. Time zone difference. I'm about 12-15 hours ahead of the US.
3. Expensive phone/fax cost.
Some solutions:
1. Daily build uploaded to the US server for the US people to check conformance to specs.
2. Use emails and instant messenger alot.
3. People from US comes by every 6 weeks or so to sync everything. ($600-$1000 coach seat.)
The labor cost is about 3-4 times smaller than the US labor cost. Internet connection is slow and expensive (dialup 128/64 kbps ADSL is reasonable--$10/day. Anything faster start around $1000 a month)
I used to have weekly build and there were a lot of problems because of the divergence between specs and products. Daily build is much, much better. Divergence is small enough to tolerate vague specs.
Basically, the more feedback/communication, the less surprising the end result.
Hi, I must say that I am impressed by the skills of the so-called Indian software factories. Unlike most replyers here we've seen quite a few of them with our own eyes and these people are really more motivated and more skillfull than most comparable European software factories. Though communication is the biggest problem this is true for all software projects that are developed in separate locations. These overseas companies have never done anything else than working remote -we can't call their internal market as profitable as the european and american IT markets. Methods have been developed and it is suitable for modern software development , especially UML or 4G/L. So I'd say: go for it.. Good luck!
Don't click here. BT will enforce intellectual rights and sue for eac
Hi,
I must say that I am impressed by the skills of the so-called Indian software factories. Unlike most replyers here we've seen quite a few of them with our own eyes and these people are really more motivated and more skillfull than most comparable European software factories.
Though communication is the biggest problem this is true for all software projects that are developed in separate locations. These overseas companies have never done anything else than working remote -we can't call their internal market as profitable as the european and american IT markets. Methods have been developed and it is suitable for modern software development , especially UML or 4G/L.
So I'd say: go for it..
Good luck!
Don't click here. BT will enforce intellectual rights and sue for eac
dear Cliff,
I'm sorry, but I think your managers are right. And Brooks law does not have to much to do with it, except: to give programming outside, you _must_ do an exact specification before: and normally internally you don't; we have been doing projects with more than 250 people within 6 weeks (after functional and interface specification, without specification for implementation, before integration test) and our experience was great with software developped outside (it was about 1/3 of it).
Nevertheless, just a good (for managers: contractual valid) specification takes about the same time as development - if it is done the first time. Afterwards ( we are in version 17 of the project in the same size) we have the following calculation/ result:
specification + development = development without previous specification.
Of course you can do it more efficiently internally than with external programming; but with CLEAR INTERFACES (which is the main part of specification in my opinion - of course I do start with use cases!!!!) programming is more efficient, more professional, less agame, but work!
And much more creative!!!!
But: it depends on: are the three parties different: users, spec-makers, developpers.
In my experience: the best is to be spec maker: but to do this, you need to be trained in : spec-making (e.g. UML) AND CONTINUOUSLY in: new technologies, with less and less own practice (after 3 years: no practice at all to specify according to learned techniques!!).
Don't hope to disappoint you,
thurn@emailfyi.com
piedro!
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.
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.
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
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
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?
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.