From the Trenches of the Enterprise Software

Yakov Fain

Subscribe to Yakov Fain: eMailAlertsEmail Alerts
Get Yakov Fain: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java Developer Magazine, Enterprisey IT Journal, Outsourcing on Ulitzer

Java Developer : Article

What CIOs Should Know About Outsourcing Enterprise Java

Your manager Frank started the meeting by saying that the budget for the new project had been approved

Your manager Frank started the meeting by saying that the budget for the new project had been approved, but half of the project will be outsourced to a great team from overseas. Can you imagine, their rates for Java programmers can go as low as $15 an hour!

No, we're not losing anyone from our team, and you should take it as an opportunity to work as team leaders, helping our new partners to hit the ground running. No, this wasn't my decision; it came from above.

Three Months Later
Mary. I've asked them to add two fields to a JTable on the Invoice screen. The data are being retrieved from our database so they'd need to modify an SQL query as well. I've sent them this e-mail yesterday, but it was night time over there, so they've responded today asking me to send them the modified SQL and write the name of the Java class and method where this new code should reside. I could've done this by myself in two hours.

Frank. Just be patient, it's a new application for them. By the way, I'd appreciate it if you could stay a little longer today. We're having a meeting with our colleagues from overseas, but there's a time difference, you know… No worries, they're willing to come to work early, so we're starting our meeting at 7pm.

Six Months Later
Frank. The system has to go to UAT in two weeks. We've all worked hard, our remote colleagues put in lots of overtime. John, you're our Java expert, and you've spent the last two weeks doing the code review of that module. Why does it work a little slow?

John. Well, that module isn't written in Java. I mean, they were using Java syntax, but it wasn't Java programming. There are chunks of unused code fragments, the code isn't object-oriented, they used the wrong Java collections, and there's unnecessary synchronization all over the place. But I can re-write the entire piece in three weeks.

Frank. OK, let's do it - but quietly.

After spending many nights in the office, the project was saved. Frank got promoted for delivering the project almost on time and showing "strong leadership in managing cost-saving external resources." But the team's morale went down the drain; two local resources (a k a John and Mary) got small bonuses and started looking for new jobs.

Post-Mortem Analysis
Unfortunately, more and more CIOs believe that computer programming is a commodity skill that can be bought cheaply when needed and replaced easily like a receptionist, mailman, or any other clerk. They don't believe that having a pool of knowledgeable and talented developers adds any value to the organization. This wouldn't be the case if the development managers (the Franks) explained to them the price that's paid for the success of such projects. But most of these managers never do this, because of conflict of interest: Frank's only goal is his smooth movement up the corporate ladder. Moreover, to increase his importance, Frank inflates the resources needed for the project on purpose. The CIO doesn't have the budget for several additional $70K-a-year developers, so he settles on the same number of $30K developers from overseas with similar résumés. Realistically, the "cheap" labor is actually an additional expense on top of the salaries of local employees.

Another hidden expense is the extra time spent writing super-detailed functional specifications and validating the overseas work. Here's one more: for security reasons, you may have to create and maintain a separate encrypted version of your database for the offshore team.

Having said all this, I can't blame the overseas developers. Their countries are experiencing a golden IT rush, so young kids are ready to dive into muddy Java waters after spending several months in vocational school (if I were in their shoes I'd do the same thing). They put in long hours trying to learn programming and the business of their rich clients (not to be confused with "fat clients") on the run. As a result of this IT boom, the turnover rate in offshore teams can be as high as 100%. You can often see it just by looking at the source code. Sometimes you get a feeling that a 200-line Java program was written by 10 different people of different qualifications. Forget about naming conventions, design patterns, or any programming style.

Hey, Frank, if you need seven people for a project, have the guts to say seven and not 10. Yes, you won't have a chance to manage an international (or as they like to say global) project, but you'll definitely sleep better at night. Before giving a chunk of your project to a company overseas, talk to your developers and ask them if they really need this help. Your developers are human beings and not just nameless resources.

On the other hand, outsourcing works fine for small businesses because both parties know that the owners of such businesses count their money and won't pay for poor-quality jobs. It also works when you hire an offshore team of senior people who know the business you're in. No, their rates aren't cheap, and don't have to be! But such teams usually consist of professionals, who take pride in their work, deliver on time without putting an extra burden on your own developers, and even mentor your staff. This is the outsourcing I vote for, but I'm not the CIO of your company.

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs ( and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Comments (9) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
J 04/28/06 04:30:54 PM EDT

Outsourcing is not the problem -- lack of visibility into the process is. Most people don't realize a few things about outsourcing:

(1) Regardless of where the work takes place there are still business folks and tech folks. Misunderstandings WILL occur. They are just that much more difficult to overcome when there is a liason and thousands of miles in the middle.

(2) They same percentage of stupid and smart people are in country x as here. Even though the percentage is the same, the total population is in most cases larger. Quantitatively that means that you have a good chance of getting more stupid people on your project.

(3)Just because a company is CMMI level certified, that does not mean every person who is delivering your project will be behave in a CMMI manner.

(4)Complex business models often requires complex software. Complex software typically needs more management oversight --- not less.

Just my 2 cents.

Isaac Sacolick 03/08/06 10:17:55 AM EST

Yakov -

There are some legitamite reasons why its beneficial to outsource a software project. Cost is a major factor, but a major reason projects get outsourced is when an inhouse team doesn't have the skills or resources to complete the job.

Also, it appears that your team of Frank and John are ill equipped to manage and outsourced project. Teams need to step up their communication , implement different quality control and project management processes, and be real team players when participating in an outsourced project. I would guess that an inhouse project with this team would have its own set of issues.

There are additional comments on my blog.

Rishindra 03/07/06 01:48:35 PM EST

Hi Yakov,

I am surprized to read this article. The way you have presented overseas programmers shows that you do not possess the real facts. It may be possible that you had bad experiances by choosing really cheap labour, which never represents the whole lot of overseas programmers. Companies like IBM/BEA/Sun/Microsoft (just to name a few) are not only just getting cost savings but also a great pool of talent which they wont possibly get in other countries.

Also, Overseas programmers should not be blamed for poor decisions to deliver in impossible time frame, bad designs, poor knowledge of business by people who are offshoring the work.

I have personally seen both the sides of this, i have worked as overseas programmer and now working as onsite programmer. Most of the times, i have seen, execution of offshore project is never controlled. Poor design decisions are forced to implement. Bad business knowledge is asked to implemented and later on it goes through a messy maintainence phase. Deadlines to deliver the code are impossible to imagine.

I agree to it when you say outsourcing should be well planned, and not just for the sake of dirt cheap prices. But Please dont blame it onto overseas programmers, there are all kind of programmers available everywhere, why just blame overseas??

Yakov Fain 02/23/06 07:52:56 AM EST

Hi Alex,

I like the way you've turned this discussion in an opposite direction! I know, most of the old code in the corporate America is a mess, but let's not create more mess by adding low-skill coders from overseas. I'm sure, there are top-notch developers in any country and your company may be one of them, but in general, outsourcing a project just because someone offers you dirt cheap prices is wrong. Period. Outsourcing has to be well planned and done by the right people, and not mediocre Franks worrying about nothing else but their career. Such Franks exist in large quantities in the Western corporate world.
As to programmeing quality, I believe in 20/80 rule: every team of software developers has 20% of people, which design 80% of the work. Implemenation is done by the 80% crowd. But the project goes down the drain when if these 20% are absent.

I'm not familiar with Chinese programmers, but I know that Russia has lots of talanted people, who (in the future) should be better presented in the world-wide business development. See my blog at

I do not buy the statistics about awards in programming competitions. Life is lot more complicated than school education and these awards. USA is not doing good in all these competitions, everyone is saying that american school education is poor, but guess what, USA is one of the most developed countries in the world for years. There's something more than winning awards.

Anyway, I like your post

Best regards,

Alex 02/23/06 12:33:23 AM EST

Hello, Yakov,

I believe you just were unlucky and had bad experience. You seem to have worked with some companies from India. Did I guess? If you have ever worked with companies from Russia or China? Try, and you will change your opinion to the opposite one.

I'm working as an architect in outsourced project. The huge world-known IT company outsourced to us a big project - porting SmallTalk application (developed by this IT company during 10 years) to Java. We succesfully did that job and fit deadlines. But we discovered many interesting things about this company.

The code written by their developers was simply a mess. It was not structured. They seemed not to be familiar with any design patters. Even basic patterns like described by GoF were not known to them. Different part of the system were developed by different people who didn't have common approach for implementation of similar tasks. As a result similar functions often worked very different when called from different entry points. Bugs fixed in one places were not fixed in other places.

That system has developed over 10 years and was used by more than 1400 users. But the application didn't have any single specification document! In many cases nobody could say exactly how the application SHOULD work with specified conditions. Often they didn't even know how it really DOES work. In many cases it worked absolutely different from what their SMEs (subject matter experts) expected! The only way to know that was to see the source code. Analysis of source code revealed a lot of errors. We found more than 250 bugs during first two month.

And all that time (10 years) their customer believed that they pay money for good work.

During two years of working on this project this IT company prepared prototypes for several susbsystems. Their value was less than zero! It looked as they simply assembled some tutorials and hints from Sun, JavaWorld, JavaRanch, TheServerSide etc. From the code of prototypes one could conclude that the authors were absolutely unprofessional people. One could suppose that authors are first-year students, whereas they worked as developers for 15 to 20 years. My experience shows, that most products (including Open Source ones) have some bugs, or limitations, or problems that developers have to overcome. E.g. we implemented workarounds for problems/bugs in Castor, FOP, Struts, and many bugs in Swing (yes, Sun also is not perfect). We couldn't wait a year or more when the problems will be fixed in Casotr or Swing, because we had have to meet deadlines (and met them).

Our partners from that big IT company were not aware of any specifics and problems of these tools/packages. Not only their developers were not aware, but even their architects! This means they have never implemented any serious application, that they have never solved any serious problem.

Not all of their developes are so bad. Our partners have more than 10 developers in the team. And only two of them do real high quality work - good and even perfect design, good implementation. The others are useless, and not only for our project, but for _any_ IT project. Sometimes they suggest a fixes for some bugs (normally it's our responsisbilty to fix all bugs). Often we have to reject them and fix by ourself, because their developers don't see the whole picture of the application and their fixes lead to problems in other subsystems.
They cannot do even such simple things like to format source code (just press Ctrl+F in WSAD/Eclipse), or to install code templates in WSAD. Usually their code does not contain any Java-doc. They don't follow any naming conventions.

Whereas our team follows project style guide for source code (Java-doc, formatting, naming convetions, convention for control statements, some metrics for classes - size, hierarchie, cohesion, etc.). Regularly we review the code (manualy and with JTest) and fix any findings. This is common practice for us.

We have well documented source code. We have specification for all functions in the application. We have well documented test cases for all functions. We have unit tests for base functionality. We have Win Runner scripts for many functions. Whereas our partners from that huge IT company have only messed souce code developed in 10 years.

Well, while working on previous project, I met real professionals in american and european
companies. And our company has professionals of the same level.
Of course, american programmers initiated many Open Source projects that are
used world wide. Despite I'm not involved in any of them, I found and reported several bugs
in Apache HTTP Server and in TomCat. I analyzed them and reported at Bugzilla, and they
have been fixed (I can provide you a links to those bug reports).

Several remarks about your example - add two columns to table on form.
1. If somebody comes to developer and just asks to add change the table/form,
it means following. You don't have established normal development process, you don't have
specifications, you don't have test cases.
2. It means that your application has a few users (3? or 5? more than 10??),
and such change will suit all of them.

Our application has more than 1400 users world wide. The same visual forms (views)
differ depending on locations. Users in Europe need one set of fields on the form,
users in Brazil - another set (most fields are the same, some differ),
users in Asia - yet another set. And before any change implemented,
it has to be analyzed and approved by customer, and has to be described in specification.
Then it has to be tested to ensure that none of other funstions has been broken.
Otherwise two columns added for users in Europe will produce invalid outlook,
or even invalid printed documents for users in Brazil. This would mean wasting
of cutomer's money.

About communication speed. We have regular telephone conferences with our partners.
In urgent cases we can call each other immediately, without wasting time on e-mails.
Normally our development is planned in 5-6 months ahead. But in case
customer needs some minor changes ASAP, we do that in a couple of hours
(later on this will be reflected in specification - always).
But such cases are very rare. Normally customer wants us to follow full development cycle -
implemntation, testing, acceptance, deployment to production environment.
Our customer is a serious company, and they don't deploy any untested and not approved
code to production. They care about quality and wish to have stable reliable system.
If some serious nug is found on production, we prepare fix and send it ASAP.
In a couple of hours it is deployed to production.

It's obvious that before outsourcing any project or its part the consequences should be evaluated. I belive that high-level organizational/management issues should not outsourced. As well as any coordinational work. As well as integrational testing with third-party systems. As well as help-desk, which should be as close to customer as possible.
Also it's bad if any ongoing work is outsourced.

Why did you say: "so young kids are ready to dive into muddy Java waters"?
Proably you think that foreign software companies exist as many years as they appeared on american
market. That's not true. They just worked in their own contries, and you just didn't know
about their existance.
Do you think that programming in other countries has started developing in a few last years?
That's not true. I personally have 14 years of exerience. Some of my managers work in IT indutry more than 25 years.
Guess who is at the top of programming contests, olimpiads? Americans? Rare. Often - chinese and russians.
So, who are "young kids"?

I belive that to achieve success the work should be outsourced in a reasonable way.
Of course, outsourcing adds some costs. Long distance, cultural/national
differences, time zones differences (in the end) increase total costs. Obviously, if application has single
visual form with three fields and single table in database, there is no reason to outsource it.
On-site team usually has better knowledge of business logic, often has close communication
with customer, can do coordinational/management part of work.
Whereas relatively isolated and technical work can be outsourced.


Sergey Vlasov 02/22/06 02:59:58 AM EST

Thank you Yakov, your articles are always pleasure to read.
Just my coin - IMHO your point about qualification of "overseas" programmers, thought I believe is correct currently, might be irrelevant in close future. In other words, they'll learn. Actually, no one says now that, for example, Taiwan electronic specialists are inadequately qualified.

Steve Richter 02/17/06 09:10:28 AM EST

I can state that this isn't just a single bad experience from the author. In fact, overall his situation is worked out out better than mine is at the moment. I'm currently embroiled in the same situation at my company, where we have been ordered to use off-shore labor on all new projects. Even ongoing work needs to be sent over, and the time required to bring them up to speed is causing missed deadlines and late nights all over the place.

Off-shore labor can work, but it requires a lot of planning and a different approach to running a project that involves on-shore reps and a lot of travel both by the contractors and the contractees, but the thought of "programming as a commodity skill" and the interest of cutting all costs doesn't allow for that.

SYS-CON Australia News Desk 02/16/06 04:19:07 PM EST

Your manager Frank started the meeting by saying that the budget for the new project had been approved, but half of the project will be outsourced to a great team from overseas. Can you imagine, their rates for Java programmers can go as low as $15 an hour!

Bruno Silva 02/15/06 03:13:43 PM EST

I find this article just promotes prejudice against people/organizations from other countries. Just because the author had a bad experience with a team from overseas, that does not make all teams from overseas incompetent. My opinion is that the same could happen if the team was US based and that the real problem lies on not knowing who to outsource to and not on the team location.