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.
High hourly rates don't guarantee quality
A less important but all too common outsourcing misconception involves the relationship of a supplier's hourly rate to its ability to create quality software. Potential clients see one outsourcing supplier charging 0 per hour and compare it to another charging 0 per hour and erroneously assume the latter produces higher quality code. The currency fluctuations in the supplier's country and the local economy of the specific region in the country can play a large role in a supplier's price, in the same way that Silicon Valley Java engineers earn more on average than their peers in other parts of the US. Moreover, different suppliers with equally qualified engineers can realize vastly different operating costs, which affect their bottom line and ultimately yours as well. If a supplier boasts about how all their engineers have private offices with flat panel displays and modern furniture, remember that your company, not theirs, pays for such luxuries in the form of higher hourly rates, and you won't necessarily get more bang for your buck.
Is outsourcing for everyone?
Outsourcing Java development should be viewed as another tool in a company's toolbox to solve its business problems. Just as not all tools are right for all jobs, not all Java projects lend themselves well to outsourcing. Indeed, understanding when to use outsourcing is as important as understanding how. The amount of coordination involved in offshore outsourcing can make small projects less likely to be cost efficient. Unless you can leverage an existing relationship with an outsourcing supplier, the amount of time and money you spend on developing the relationship will be difficult to recoup in the space of a single small project like an applet. This does not mean that the first Java project you outsource should be an enormous J2EE undertaking, simply that there is an investment you must make in setting up any such long-term partnership. But once you make the investment in the first project, you will reap the benefits in all subsequent projects.
As mentioned above, projects not defined in detail probably won't lend themselves well to outsourcing, and this includes projects that simply cannot be defined in detail up front. While this of course includes pure research projects or any system in which the state of the art is being pushed in more than one direction, it also can include simple yet highly visual projects like Java Server Pages. Even though the concepts behind a Website are easy to grasp, articulating all of the presentation-specific HTML requirements in a written document can sometimes take more time and be more frustrating than just coding the page itself. Sure, the presentation layer and the business logic can be kept separate and implemented by local artists and remote Java engineers, respectively, but this probably makes sense only if the business logic is sufficiently complex. On the other hand, these rules of thumb may fall by the wayside if you simply cannot find Java engineers in-house for your project, or if using them would poorly leverage their skills.
Assuming top management stands behind both your project and your decision to use offshore outsourcing for Java development, as your next step select your technical project manager, as this person acts as the chief point of contact between your organization and the outsourcing partner. Managing even a modest project remotely can easily be a full-time role, so you want to make sure you find a manager who can commit to the project's success. Ideally, you want someone who has experience managing remote projects, can visit the site for extended periods if necessary, and can be flexible in accommodating whatever time zone differences may exist. This manager must also be well-versed in translating business requirements into articulate technical specifications (perhaps even down to the object model), as well as be able to work closely with the business side to ensure both parties can answer in harmony to any project questions posed by the offshore team.
Selecting a staffing partner takes some time if your organization is unable to leverage an existing relationship. You are to some extent trusting your business with this organization, so you will want to have your company's representative visit the site, interview potential team members, follow up on references, and discuss the pilot project in as much detail as possible. The initial few weeks of the relationship are crucial, and both parties must make sure to over-communicate on important topics such as scope, schedule, quality, cost, risk, and personnel, at least until the partnership rests on solid footing. Once the process is in place to facilitate close monitoring and elaborate progress reporting, you'll have all the ingredients for a successful outsourced Java project as well as the means to enjoy many more.
Offshore development marches ahead
Throughout this article, you've seen how offshore outsourcing can save your organization time and money in its Java development efforts. While examining the potential advantages this strategy can provide, you also saw that these benefits come only under the right circumstances: when both the project and the project leadership lend themselves well to outsourcing. You further examined how to get started on an offshore project, although arming yourself with the information in this article serves as a great first step.
As software development becomes less of a benighted art and more of a well-known system integration effort, it makes sense that pieces of the software process will become commodities. This change in software construction's perceived value may lead some companies to shift their focus and core competency away from writing software and toward managing their own offshore software development process.
Learn more about this topic
- National Association of Software and Service Companies
- The India Software Network
- "Offshore Outsourcing," Loretta W. Prencipe (InfoWorld, February 2001)
- "Offshore Outsourcing Nears Critical Mass," Drew Robb (InformationWeek, June 2000)
- "Outside Development Partners," Andrew Binstock (InformationWeek, October 1999)
- For more interesting opinions on the Java industry, visit the Commentary section of JavaWorld's Topical Index
- Sign up for the JavaWorld This Week free weekly email newsletter to learn what's new at JavaWorld: http://www.idg.net/jw-subscribe
- You'll find a wealth of IT-related articles from our sister publications at IDG.net