The Old Joel on Software Forum: Part 3 (of 5) - Outsourcing

Outsourcing - making it work

My company is ramping up for a project which will involve internal developers (including myself), local-but-offsite developers, and offshore developers. This is our first time working in such a distributed fashion. Naturally, the project schedule is too short and we're looking for ways to mitigate the risks of failure. Here are some of the practices we've set up to (hopefully) do so in terms of improving the efficacy of the team:

- Iterative development. Each development iteration will be two weeks. A "customer delivery iteration" is planned for the two, four and six-month marks, the first one being a dry run to prepare for the real deliveries.

- An email equivalent to the daily stand-up meeting, where each developer sends an email detailing what he did today, what he's planning to do tomorrow, and what his roadblocks are.

- Code reviews. All code is reviewed by a senior developer against a best practices guideline to catch both common design errors and faulty coding practices.

I'd like comments/feedback on these practices as well as your experiences on practices that have helped your own team when working with offshore/off-site developers. "Lessons learned" experiences are also appreciated.

Thanks in advance.

Searching for Success
Sunday, December 21, 2003

Unless you have a specific business reason for not doing so, I suggest archiving said emails where they can be accessed by ALL involved in the project.

Many eyes and all that. Someone in another part of the org might be able to solve the problems, or just make them go away.

Tapiwa
Sunday, December 21, 2003

Based on that geographic distribution, and the realization already that the schedule is too short, you're doomed. Unless the requirements are set in stone because you're doing something like converting an existing system into a new language to make it do EXACTLY the same thing as it was doing before, or you are writing drivers for hardware that is already built.

Otherwise, if your job depends on the success of this project, start looking for another one now.

T. Norman
Sunday, December 21, 2003

Create UML and generate classes and interfaces. Your off-site developers should fill in logic in all these methods/templates. This will also help to better do code review.

Consider to use chat/whiteboard to talk to remote workers and quickly solve technical problems, if occur (it is also more cheaper than phone calls).

Evgeny Gesin /Javadesk.com/
Sunday, December 21, 2003

I'm curious - is this a point and click database app? Or is it backend processing? Device Drivers?

-james

James Wann
Sunday, December 21, 2003

A good choice for archiving those e-mails is a password protected Wiki. The team lead takes the e-mails, and quickly puts them up onto a new page for every day. Might take a couple hours to set up, and then a few minutes every day for the cut & paste.

Anything heavier weight will probably fall into disuse.

Brad Wilson (dotnetguy.techieswithcats.com)
Sunday, December 21, 2003

Or cc a copy of the emails to your FogBUGZ database. Then it's sorted, searchable, web visible, and no manual cut and paste required.

Joel Spolsky
Sunday, December 21, 2003

You said it yourself - the project schedule is too short.

If someone tries to load to much cargo into an aeroplane, do you know what the captain of the aircraft does? He refuses to fly it.

Sunday, December 21, 2003

And when he doesn't refuse, tragedies like Aaliyah's crash happen.

T. Norman
Sunday, December 21, 2003

I've done something similar, with some success.

First, online chat is mandatory. Cancel the project now if you can't arrange to have all developers have access to it at all times. Also, everybody needs to work in the same time zone, even if they aren't physically in the same time zone. Otherwise you'll have tremendous lag.

Second, you will still need face to face meetings from time to time. That's because the impersonal nature of electronic communication is going to cause problems. The fellow you think is a first class rectum via e-mail and phone will often turn out to be a really swell guy in person, who you can work with smoothly.

Clay Dowling
Sunday, December 21, 2003

You don't specify the nature of the offshore team. Perhaps the offshore developers work for your company, in which case the system you describe might work. However, if the offshore developers are working for a body shop (e.g., one of the Indian outsourcing companies), don't expect much give and take. Those guys are paid to meet their company's commitments, not your project goals. If "submit daily email on activities" is not in the contract, you won't see daily emails from offshore.

Don't make the mistake of confusing offshore body shop developers with employees. Different people, different organizations: different goals. You need to understand this difference to make it work.

Bob
Tuesday, December 23, 2003

"Don't make the mistake of confusing offshore body shop developers with employees. Different people, different organizations: different goals."

VERY good point. The offshore body shops are in business to make profits, but the client is using the offshorers because they want to spend less. Those are two deep conflicts of interest.

That conflict of interest can lead to increased costs if you are not vigilant with communication and contract negotiations. If there is a requirement that can be interpreted in more than one way, they will tend to interpret it in the way that is most profitable for them. The low rates they charge force them to become very creative in making you spend more without you realizing it or resisting it.

For example, you ask for eggs, so they bring you scrambled eggs. You actually wanted hard-boiled eggs, but you can't penalize them because you asked for eggs and that's what they delivered.

So you pay them once for the scrambled eggs you didn't want, then you pay them again to do it hard-boiled. But your employee (whether that employee is local or offshore) would have first asked you what type of egg, or would have known it already based on their experience in your business.

T. Norman
Tuesday, December 23, 2003