Take Java offshore

Should your organization outsource Java development overseas?

From small Silicon Valley startups to the Fortune 100, many companies are discovering the benefits of outsourcing Java software development to offshore teams. Gone are the days when US firms outsourced only the tedious legacy systems maintenance to offshore companies. Indeed, US-based companies spent .5 billion on offshore outsourcing last year, an amount predicted to rise to 7.6 billion in 2005, according to research firm IDC. With the available and inexpensive talent pool of Java developers in countries like India, Russia, and Ireland, outsourcing new development efforts using the latest Java technologies can save companies time and money, and might be a great fit for your organization's next project.

While putting an offshore outsourcing plan into practice can be tricky, the basic concept is fairly simple: your organization articulates the business problem it wants to solve, while an offshore Java development team constructs the solution. This scheme imposes a greater degree of compartmentalization to the software process than what you might be used to, in that the offshore software engineers and the onsite business managers may never so much as send an email to one another. Instead, the majority of the communication funnels through the project managers on each side. This makes the software construction process much more analogous to that of building a house. For example, if you build a new house from the ground up, you would ordinarily deal with an architect, who would in turn deal with general contractors, who would then manage construction workers. If you suddenly wanted gold inlays in the countertops, you would not walk up to a carpenter at the construction site and order it done. If you think, "Well, I should be able to!", then outsourcing is probably not for you. Otherwise, read on.


When considering outsourcing a Java project, managers naturally want to know how much it will cost and how long it will take relative to the traditional in-house approach. While it is tempting to sum up the potential benefits of outsourcing in terms of the dollars and man-months you will save, too many variables exist to make such a generalization meaningful. Instead, it pays to understand the variables themselves and then come to your own conclusion.

Yes, costs are low

Of course the factor that often draws the most attention is the low hourly billing rate for offshore engineers. While rates have increased dramatically in the last few years due to the explosive growth of the outsourcing industry, companies can still find excellent Java talent for 0 per hour, although prices up to 0 per hour are becoming more common. These numbers are dreamy compared to the lofty figures that even mediocre Silicon Valley engineers command in today's market, and the numbers get even better when you account for other employee costs such as sign-on bonuses, stock options, health-care overage, office space, equipment, and those hefty recruiter fees you pay just to get them on board. And hiring does not just cost money, it costs time, another crucial factor to consider when evaluating offshore Java development.

Build teams quickly

For some companies, the time it takes to put a team together eclipses the time spent developing the application. Both juggling internal resources and hiring new employees can delay a project indefinitely. Provided you are not looking for Java engineers who also possess some arcane skill set, outsourcing suppliers can generally have a team of qualified engineers assembled within days, although you can extend the process by interviewing the individual engineers yourself to ensure their suitability to the project.

Manage the project, not the employees

The benefits in human resources management continue even after the offshore team is in place, as you focus on managing engineering work, not the actual engineers. That is, while your organization is still ultimately responsible for the software produced by the offshore team, the supplier deals with HR issues, like an individual's career goals and the political consequences of giving him the cubicle near the window. What's more, as many companies have discovered, you may find it easier to work with engineers in offshore companies compared to many hot-shot American engineers. While culture often acts as one factor in these differences, as a bigger influence, offshore development usually proceeds as a team effort rather than based on the talents of an individual engineer.

Emphasis on quality assurance

With such potential for time and cost savings, companies often assume they must sacrifice quality if they employ an offshore team. Not only is this fear unfounded, but you may actually find the deliverable's quality better than what you would expect from local talent. Java engineers at reputable supplier companies tend to be well-trained in the fundamentals of software engineering as well as the specifics of the various Java APIs, and these skills are honed as the engineer moves from project to project, picking up best practices along the way from different client companies.

Perhaps even more impressive than their software development skills is their emphasis on quality assurance (QA), an aspect of the software lifecycle often treated as an afterthought in American firms. No doubt this is due in part to the difficulty in finding local resources properly trained in QA techniques who are motivated to do this often tedious job. For client-side Java development efforts, having an experienced Java QA team can save the day. By testing the application or applet early and often on a wide variety of OS platforms, JRE (Java Runtime Environment) implementations, and browser environments, these ready-made teams spot problems early in the software lifecycle while they are still cheap to fix, and relieve you from having to maintain a full QA lab locally. For server-side components, you have the luxury of being able to add and remove dedicated test-harness developers as needed. Finally, Java QA and software engineers in offshore companies often enjoy a long history working together in the same company, facilitating free and efficient communications among the team members.

Experienced development teams

Many offshore development companies emphasize more than just QA, however, in that they recognize the importance of software methodologies and the processes behind them. While most suppliers will have their own preferred methodology that has evolved over time, an outsourced project team can adapt to your desired process, whether a brand name like Rational Unified Process or your own in-house approach. Such a structured focus on software development carries over into areas such as training. Suppliers try to keep some small percentage of their engineering workforce on the sidelines to act as a buffer against spikes in demand for personnel, and whenever these engineers are not assigned to a client project, they are learning the latest J2EE (Java 2, Enterprise Edition) technologies, applying them to internal projects, and then sharing what they learn with the rest of the organization. This allows the supplier's workforce to have useful experience across a significant portion of the ever-expanding Java platform.

Your Java project may require only five engineers, but you'll get the collective experience of the dozens or hundreds of engineers across the company. This availability of people trained in leading-edge Java technologies is one reason offshore services firms are being contracted to develop sophisticated new Java-based systems, rather than merely maintain legacy C++ and Cobol systems as in the past. Some outsourcing suppliers have found that their entire workforce has migrated from C++ projects to Java projects in the space of one or two years. Completing high-profile projects using some of Java's more advanced APIs goes a long way for a supplier's credibility, to the point where they might hesitate to accept new C++ projects.

Give the turnover headache to someone else

Sidelined engineers also receive training by being assigned to various client projects as the engineering equivalent of an understudy. An often undervalued result of this overlap is that attrition tends to be managed gracefully. In-house projects can be delayed or even derailed when Java engineers move on to other projects or just jump ship with little notice, a delay largely due to the reluctance of management to factor attrition into the project schedule. Even the best outsourcing firms realize they cannot avoid attrition, especially with so many young Java engineers wishing to move to America once they have a successful project under their belts. As a result, many overseas firms embrace attrition, expecting it as a natural part of the software development process. The consequence of this expectation: projects tend to be well documented from the outset, and when the inevitable does occur, a clued-in replacement stands ready to carry on. Over the course of a year, your project team may experience 100 percent turnover or more, and yet continue to gain momentum as though they had been together all along. This resilience actually increases as your relationship with the supplier grows over time, so that the more you use them, the more you want to use them.

Despite all of these advantages, many organizations resist outsourcing their Java application development. As some managers receive compensation according to the size of the team and budget they manage, reducing headcount and cost is counterintuitive on a personal level even though it makes sense on a project and company level. Because of this, the outsourcing decision often rests at the management team level. Also, local engineers may feel threatened if the new EJB/Java Message Service/Swing-based project gets assigned to a team in Russia, so managing the politics can be daunting.


Allured by potentially enormous cost savings and improved time to market, some Java software managers approach outsourcing like moths to a flame, only to be burned by their own misconceptions about the need for local management, extremely well-defined specifications documents, and equating an hourly rate with quality.

Success depends on good management

Possibly the biggest misconception surrounding outsourcing is that offshore projects do not require as much management as their local counterparts. Some clients would almost believe that they can write a high-level specification, throw it over the fence to an anonymous group in India, and have a floppy disk with a jar file thrown back over in a few months with perfect software. That is as much pure fiction with outsourced projects as it is with in-house efforts. Creating nontrivial Java software proves complicated no matter where it takes place, and offshore software projects need day-to-day management just as local ones do. With additional hurdles such as differences in time zones, languages, and culture, the actual management of the project team, both at the business level and the technical level, becomes the single most important factor to the project's success.

Solid documentation saves the project

Some clients mistakenly assume that the same specification documents they use for in-house projects will suffice for offshore efforts. The offshore team's ability to deliver correct software on time is proportional to the client's ability to write a clear and thorough functional and technical specification. But with seemingly infinite Java resources just on the other end of an email, some managers erroneously believe they can make up for laziness in the specification process by throwing more people onto the team. No amount of offshore resources will rescue a poorly articulated project. Managing remote Java teams requires much more discipline in the project's elaboration phase than it does when all stakeholders are colocated. Completely local teams with less experienced management might enter a fairly tight loop where engineers repeatedly tinker around for awhile and ask, "If we built something like this, would it be a good thing?" Rather than be forced to elaborate on the requirements up front, the managers can just keep popping into the engineering area asking for changes and additions until something useful compiles and runs. While this sort of practice can possibly work for entirely local teams, it will surely fail when applied to offshore teams.

American clients sometimes place unreasonable expectations on the engineering maturity of offshore developers. Extrapolating from a few experiences they've had with superstar expatriates in the USA, some local managers believe they will get a whole team of such hotshots, each with a dozen years of experience, all for 0 per hour. While the engineers will almost certainly be bright and knowledgeable of many aspects of the Java platform, they will most likely be in their early to mid-twenties, with just a few years of real-world experience behind them. From a technical perspective, this means that while the engineers can certainly make use of all the fancy J2EE technologies, they might not always understand why to use one over another, or which design patterns make up the best practices for your project. The lead engineer on the project needs to be diligent in checking for the pitfalls common in young Java engineers everywhere, such as inadequate use of abstraction, promiscuous instantiation of objects, and failure to ensure multithread safety.

1 2 Page 1
Page 1 of 2