Product Analysis: Imported Java

The Project

NWC Inc. is a small manufacturing business headquartered in Green Bay, Wis., with production facilities in Syracuse, N.Y. Our customer-order systems let users buy "widgets" that are built in Syracuse. The widgets we make may be figments of our imagination, but all the systems required to run the business are real. Internally, we can track item delivery and show when and how our products shipped. However, we had no mechanism for support personnel to track all orders for a customer or to check the status of an order.

Our order-entry system is based on Oracle using JSPs (JavaServer Pages), and our shipping/order tracking system is based on Microsoft SQL Server using ASP.Net. We asked Patni to develop software that used both of these systems to show all orders, their shipping status and how they were shipped for a given customer. We built a requirements document and asked the company to bid on the project. Our proposed time line was about six weeks, and the system would require several JSPs to be written that would access both Oracle and SQL Server. The project required writing code to access and update databases the developers had never seen and would use development tools determined by our Web development environment, which incorporates Oracle's version of Apache with the Tomcat Java Application Server. To simulate the changes that happen in real projects, the final target was Oracle9ias. Although the project was challenging, we didn't specify a complex system, mostly because of tight deadlines. See "What We Sent Patni" for more on our original requirements document.

Early Problems

Patni's response to our request included a document detailing its proposal and delivery time lines for items that both our company and theirs were responsible for. We agreed not to publish Patni's man-hour and cost estimates because it was the only vendor participating and disclosure might harm it competitively. As a ballpark estimate, the original quoted price was close to half the annual salary of a developer. This figure included analysis, design and implementation. Note that we undertook no negotiations around this number, but you should. Outsourcers are out to make money; you are out to save money.

It quickly became apparent that the total costs on our end would exceed the quoted cost from Patni because we had to: give its developers access to our systems and troubleshoot remote-access problems; provide documentation on how to access the databases; build a separate test environment to separate the new app from internal projects; and replicate our test databases and Web sites to this test environment.

We also realized that Patni is accustomed to dealing with customers much bigger than our little selves--it was prepared to begin work, waiting only for us to provide access over a VPN. But our VPN is a down-and-dirty installation, while Patni is set up with Cisco VPN gear. Of course, we would have run into the same problems with any outsourcer, and though we could have worked through these compatibility problems, we were on a deadline and the Patni team was waiting for us. To the company's credit, it was only a day or so before Patni agreed to use our VPN and determined how to gain access.We thought that getting rights configured so that developers had access only to the necessary machines would take us just a couple of hours. But then we discovered that Patni couldn't connect to Microsoft SQL Server through the VPN. We spent two days researching solutions, only to find that our VPN required remote users to have login rights to the SQL Server machine for ODBC to connect through the VPN. This made us less than happy with our VPN product, but Patni's patience was heartening. All totaled, NWC Inc. staff delayed the start of the actual coding by nearly two weeks, and yet Patni delivered product only one week late. That means five weeks from first line of code to acceptance testing.

The benefits of outsourcing this development were minimal for us. With only two full-time IT staffers at NWC Inc., we are responsible for developing and deploying the original databases and Web pages, and we could have built the app in the same amount of time Patni did, mostly because we already knew the software architecture and had our own test systems configured. So, in a nutshell, our small organization saved almost no time but would have spent the salary of a third IT person.

Much of this seemingly large cost is simply a factor of project size and fixed overhead. We had Patni's project manager on-site for two weeks. That's a lot of time in the scope of this small project, but in larger projects and larger shops, this overhead is quickly absorbed by the small incremental costs. Had we been paying for the project, the cost of hotels and airfare from India, not to mention conference calls, would have grown significantly, but not as fast as actual deployment costs.

Larger shops, on the other hand, could sidestep many meetings and reviews--analysis, design and code reviews were handled by Patni staff--meaning that the cost may have been significantly less for them than developing the same software in-house. Although you must gauge the total savings versus total expenses of outsourcing, as a general rule, the larger your organization and the more involved the project, the more likely you'll save money using an outsourcer.

Furthermore, though we had to grant access to our systems and perform acceptance testing, we didn't participate in the overall development process. This is where your comfort level comes into play: If your organization requires tight controls, costs may go way up because in-house IT would need to vet each piece of the project while the outsourcer waited for approval. But for organizations willing to simply control requirements and let the outsourcer worry about implementation details, huge savings are possible. We reviewed the initial proposal, analysis documents, architectural overview, design documents and test scripts. We had input into each stage of the development process without having to stop that process (see our time line, for additional details).

Speed Bumps

Outsourced application-development projects often have more problems than those done in-house-- the people doing the work aren't as accessible as the developer down the hall. The largest stumbling block for us was the time differential--about 11 hours--which meant conference calls outside of normal work hours and waiting a day for most problem to be resolved. This lack of accessibility can be a bonus, though, if you account for it up front. For example, how many of your projects have run over budget and overdue because the available staff had other responsibilities? A developer half a world away can't be pulled off a long-term project to tend to fires.

Here are some must-haves that will eliminate a few bumps along the way:• A dedicated project team. Specify this requirement first in your contract. Make sure the staff is qualified and available for the course of your contract's term--at a minimum until you accept code from the vendor. Our project had three developers, a project manager and two business people on the offshore vendor's end. Our salesperson was on the East Coast, which helped with initial contact and negotiations because he was nearly in the same time zone.

• A responsible project manager. He or she will do wonders to keep things together. Our project was straightforward, yet we held up the development team three times while it waited for input on design acceptance, user rights assignment and other points. Make certain you have someone on your end dedicated to getting this project done on time and empowered to get what the vendor needs in a timely manner.

• Agreed-upon deliverables. We let Patni's development staff determine the deliverables because we wanted to see what the company would produce if not given a hard list. All we specified was "analysis, design and code." When Patni asked about coding standards, we told it to use its own, again to see what we'd get. Make sure your vendor has a copy of your coding standards, and that it agrees in writing to abide by them.

As to what we got, it was what you'd expect if the project were developed in-house: Java code with modified Hungarian notation for a naming convention and comment headers for each method. Variable names made sense and, as you should be able to expect, contributed to the code documentation.

Why not define code standards? A surprising number of organizations list insufficient code quality and maintainability as their main reason for not outsourcing again. Clearly, there are going to be good and bad offshore organizations in this respect. So we left the field wide open. With Patni, we found very little difference in what we'd do ourselves, but you should investigate potential vendors. Ask for U.S. or European references. Then ask these references about the quality of code, including adherence to specified coding standards, analysis and design, along with timeliness of delivery and responsiveness.It's also a good idea to discuss with your vendor long-term maintenance of source code. Because our developers work in Java and we had no intention of forging a long-term contract, we didn't pursue this. But if you want the offshore vendor to be involved in maintenance, you might be able to negotiate a better price for a longer-term deal, so put it on the table on Day 1.

Remember that you will have deliverables. The outsourcer will need test machines on your network that are accessible through your VPN. It will need access to your databases, or at least to test copies of your databases. And it will need logins on your network. All of that is just to get started; during the course of the project, a responsible vendor will await your acceptance of each step or milestone (user requirements analysis, functional design, solution design, code) before starting on the next.

The final deliverable must include functional test scripts and performance test scripts (if performance was part of your contract), installation tools as required and on-site support. When the deadline is here and the application is being installed, issue resolution will be speedier if someone is sitting with you to work out bugs.

The last thing to think about is support on your end. Your staff--particularly the project manager--must be aware that it's unlikely to be a 9 to 5 job. India is nine to 13 hours ahead of U.S. time zones. We handled calls as late as 11 p.m. and as early as 5 a.m. Our scheduled conference calls to track progress were Tuesdays and Thursdays at 7 a.m.; not too bad, but something to be aware of.

The time difference also can slow testing. Unless you make arrangements up front with your vendor, it will be closed while you are testing. Factor this into your plan and expect longer turnaround times or negotiate for 24/7 support during the testing phase.

Shades of Gray

So would we recommend offshore development? The answer isn't as clear-cut as, say, whether we'd recommend the latest piece of SAN hardware. With no speeds and feeds to test, we're left with many "ifs."

For most large shops, offshore development is a viable option, if you choose a reputable vendor, set reasonable deadlines and provide adequate support on your end. If you're willing to commit to doing adequate up-front preparation and assigning a project manager (or team, depending upon project size), offshore outsourcing might be cheaper than doing it in-house, but even if you don't save money, a third party will almost certainly deliver more quickly than staffers who have other day-to-day responsibilities.

Patni has a solid practice of documentation that ends with a customer-satisfaction survey. When asked to fill it out so the company could close the project, we reviewed our notes, thought about all that had happened in the course of the project and came to the conclusion that, overall, the company exceeded our expectations. We always try to be objective, of course, but we've heard so many horror stories about the quality of work offshore outsourcers turn out that we expected less than what we'd get from a U.S. outsourcing firm. It was with pleasure that we found a three-tiered architecture that was well-documented from the beginning and source code that could be followed without naming an employee as the designated interpreter.

We were a little disappointed in the pricing, for we were led on by the pervasive view that offshore development is "cheap." Turns out cheap is relative--for a small shop, outsourcing could well be more expensive than developing in-house. If your organization tends to bog down even small projects, you might spend more to pay people to attend planning meetings than you would for the entire outsourced project. The process isn't free on your end, so factor those costs into any price comparison between outsourcing and in-house development.

We were also more than pleased with Patni's willingness to adapt to schedule changes caused by our tardiness in delivering things it needed. For example, we were at a trade show the week that the functional specification was submitted, and Patni needed only our John Hancock. But we didn't provide it in a timely manner and lost two days. Patni adapted to our changed time line, providing us an updated one that reflected the changes and still met our deadlines. Although we are technologists, we still have to take time out to ensure we meet our magazine deadlines, and Patni rolled with these punches.

Don MacVittie is a technology editor at Network Computing. He previously worked at WPS Resources as an application engineer. Write to him at [email protected].

Our outsourcing project with Indian vendor Patni Systems was an experiment in the overall offshoring experience. Our goals were to evaluate the value, quality and issues surrounding an offshore implementation. We gave Patni free rein in choosing the types of documentation and coding standards to include in the deliverables--this was a little out of the ordinary, but our goal was to use this bit of freedom to gauge the maturity level of Patni's processes. We were pleasantly surprised by the results.You can find the documents that Patni submitted online here. The only modification we have made is to eliminate references to costs and man-hour estimates. We removed these numbers so Patni wouldn't suffer competitively for participating in our tests--we believe the vendors who refused to participate shouldn't have a window into the pricing structure of the vendor willing to collaborate with us on this project.

Our initial requirements document was purposely short of information. Often projects are defined only once, after which the project managers start asking questions. We chose this approach to see how Patni would handle it. You can find our requirements document here.

The first document we received was Patni's response to our RFQ. The notice at the top that this information is confidential is left in for your reference; Patni gave us permission to publish this document in support of this project.

Next, we sent our database schemas to Patni. These documents are excluded here because we wish to focus on the documents Patni provided us, not the ones we provided the outsourcer. As you know, for a vendor to develop an application with a database interface, the customer must provide the schemas, so we mention it here.The final document you'll find online is the Functional Specification created by Patni. Note that there is enough overlap with the original response that the two tie together, but not so much that it bores you senseless. This document does an excellent job of showing the vendor's understanding of the project, with only our skimpy initial documentation and some well-placed questions on its part to work from.

(Be sure to listen in to our exclusive interviews with Don MacVittie for a behind-the-scenes look at his analysis of Patni and his take on the future of application development.)

Myth: Language and culture are huge issues in offshoring.

Reality: Companies looking to do business with U.S. clients present employees fluent in English. Differing cultures generally impact relations only when culture-specific holidays cost project time.

Myth: Code quality is poor in offshore projects.Reality: Not always. Like anything, quality varies. Check vendor references.

Myth: Offshore outsourcing is bad for America.

Reality: This is anything but clear. Extra income generated by companies may well translate to more U.S. jobs.

Myth: Offshoring means no work for your IT staff.

Reality: Your IT staff must, in fact, work closely with the offshore team.Myth: The total cost of offshoring is more than the cost of internal development.

Reality: It depends on the company and the project. This can be true, especially in smaller companies, but doesn't have to be the case.