Slashdot Mirror
Managing a Global Programming Team?
cwimmer asks: "I work for a technology company in the United States who survived the economic slowdown by trimming fat where necessary. Unfortunately, it seems that my small programming team must've looked like mostly fat to management: it has been trimmed from a high of 5 to the current 2. We have been given a very large programming project that we estimated would take 4 coders (the size of the team at the time) 6 months to deliver. I have been given deep pockets with regard to moving some or all of the project to an offshore partner, and I can probably get 4 or 5 programmers in India. Does anyone have any pointers on managing a team of programmers on the other side of the world?"
Perhaps you could use those deep pockets to hire back the 2 fired programmers? 2 programmers you can actually talk to and design with are probably as productive, if not more, than 4 you can't communicate well with.
But, as has been pointed out here already, there are thousands and thousands of US developers out of work, which makes it a buyer's market. To put it into perspective, a top-gun Russian developer is going to charge 25/hr. I am certain that you can find a comparable US developer right now to do it for approximately the same; plus or minus 10% or so. It's amazing, but even software developers like to pay their mortgage... ;-)
---
SCO is weenies
Gator is Spyware
Microsoft is thugs
Budget for a lot of travel on short notice. You will need "face time." Expect the trave to exceed what you will save in salary for such a small project. If you are hiring 20 or 20 programmers you might see a real savings if it comes out right. Also, plan on switching your US team to the graveyard shift so you can have enless phone calls with them. Been there, done that.
As a programmer whose company is thinking of hiring help from a local company that uses Russian programmers, I'd say: don't do it. The amount of complications possible by far outweighs the advantages (cheap!) in my opinion.. Like: -You've got your working program. But hey! there are two major bugs in it..but the offshore team is too busy with some other job, or are not reachable for some other reason. -From experience, everything you buy that is cheap at first, might turn out te be quite expensive later. I'd say, that might as well be true for hiring programmerskills. You're gonna need people to communicate to those programmers, even if they speak english or not. That person will cost money as well, unless you're willing to give up 70% of your own time to integrate, test, debug etc. the code you're getting from them. -Losing control! What you don't make, you cannot control easily..i.e.: you can check the code itself, but not how it was manufactured, or what kind of design decisions were made. I'm sure other /. will have better stories on why you should / should not do this..Basically, I'm just saying: don't make this complicated. If you need more manpower, try looking around in your own country first.
My 2 cents..
I work as a biz/tech in NYC with a team of programmers in NZ and 2 biz in San Fran. We use:
;)
email: Message usually to "all". Projct discussion is usually ad-hoc (no lists). This is mostly for updates, documentation of happenings, clients.
IM: we use a mix of AOL, Gaim, etc. This is where most of the decisions get made.
CVS: This, plus a whole bunch of automated testing scripts (JUnit and homebrew; we're all Java) with results of this posted every 10 minutes on the intranet and ensuing complaints if you fail to keep the tree green.
Intranet: News, CVS autochecking, Product versions, Marketing, etc. Looked at WIKI, Zope, etc., but ended up making homebrew.
SSH: Everything is tunneled with SSH to keep things nice and secret
The most important thing in all of this is making sure information is received by those who need it. This is usually more of an exercise in politics than technology.
While I havent done it myself, I worked with others that have, and seen success and catastrophe. Whatever you do, don't hire somebody who is going to hedge the truth about progress. Ive seen projects completely cave in when the found out that their oversees components were months behind schedule, but the managers lied and said everything was going great. Remember they may not have the same American get-it-done attitude you have.
Also, make sure they have the same scheduling paradigm you have; for some reason a lot of people think that estimating a schedule means padding by tenfold, others think it means come up with the shortest conceivable timeline to please the boss.
Why should the nationality matter to me? All I want is the optimal price/skill ratio. I couldn't give a fuck if you're from bumfuck Somalia if your code is good, you finish it on time and don't ask for too much pay. Isn't that's what the free market system is all about anyway?
Canada has highly talented and educated programmers. Many of them, like myself, back from stints in the Bay area.
The price is right. Typical rates for Canadian consultants are 10 - 20% discount on US rates and then discount a dollar that only worth $0.65 US. No time zone issues or language barriers. Frankly, I don't understand why a US company would consider going anywhere else.
- Tune in next time for.. a clever sig.
I run a online game development business (www.murpe.com) where most of my development and support team are found all around the world (England, India, Russia, Japan), so we had to look at a common place for having meetings and discussions. There are times my adminitrative staff cannot connect to our online games (due to firewall restricts on telnet), so using web interfaces was an option we considered.
Since we are primary an linux-run development business, we found that using phpBB's (www.phpBB.com) web board system we could keep things private and moderated, then we also utilized a few web based project management suites (you can find these through freshmeat.net easier) for delegating tasks and having a calender available to everyone for upcoming milestone meetings and what not. Overall, the web boards/suites allow us near real-time interaction for discussing issues and for working on other problems when they arise.
-- M
Artificial intelligence is no match for natural stupidity.
So why should we answer this guys question, Its just helping him fire us!! Let him go to indias version of slashdot and ask THEM!
I'm sorry but I'm not stupid enough to help my boss figure out how to replace me.
This is why I'm so against globalism, this kinda thing will happen all the time as globalism becomes standard.
If you use Linux, please help development of Autopac
Having done several of these, as your first project, with deep pockets and a compressed do date, you are going to have problems. Major, miss the date, lose your job type problems if you attempt to remote source it.
Oversea outsourcing has problems beyond the traditional remote support. I have and continue to be a strong proponent of remote support. You get the benefit of hiring expertise that may not want to locate near you. For example, I work remotely for clients where the cost of living is easily three times what I pay here. And they do not offer three times the compensation. It sounds like that is what you are after. A win-win.
Here are just some of the issues:
- Time zones are more than inconvenient. If a question does not get answered by 8 a.m. , it will sit until the next day. Picking up the phone sounds easy, but will not be. How many issues can pile up before the communication is complete or they stop asking and just begin assuming? Who gets to call meetings and who attends? As the person leading the project, are you ready to work day and night? Team, status, and planning meetings need to be held with everyone so when?
- Code is not code. Simply put, cultural differences create issues in code. If you wish to own the code when you are done, both parties need to understand what is acceptable standards and what will happen with code that needs to be reworked (do you still pay while they rewrite it?). Standards for names, fields, tables, access types, how and what type of inheritance is allowed, etc. Assuming they will be coding in English (yes, you do need to make it a requirement), unless you all agree (or they have worked extensively in the US), someone will be rewriting the code. Or you will need to look at it like generated code. It does the job, but you never want to maintain it.
- Cultures different. As Americans, we tend to be naive in the assumption of cultural neutrality. And while many organizations do their best to be neutral, language continues to be a barrier. Consider how difficult it can be to understand someone with a varied US dialect. Add the phone, email, and 5,000 miles and a simple statement "You wish the account number removed, no?" takes on a whole new meaning. My unscientific number of 30 -40% redundant communication will work to minimize these types of issues.
Some companies put an American in charge from your side. You work through them and they make sure the details get hammered out with the team. This helps a little, but sounds a lot better than it works in practice. I was approached by a company to have mine work as that front. I passed when I saw the only difference was I would now have all the issues the client had, plus my own.
- What if it fails? This is the one that can be a stickler. Suppose you are being told that your project is on schedule and all the areas are coming together. The status reports look good and the code is getting delivered right up to the point everything stops. What are you going to do? While this problem exists in many contractor type arrangements, these folks are overseas in a country where use of the legal system is unknown. I hate to say it, but at least here you can sue someone if for nothing else but to get the code that was created.
At this point, I foresee a number of people reaching for the "reply - he's a bigot button." Hardly. These are business decisions and people make them from the cost/benefit. Often the price appears cheaper, because the assumption is made that given any programmer "X" they will generate lines of code "Y" and the result will be the same. That is not the case and is simple as the difference between hiring a person out of school and one with 10 years experience. The both know C++ so the results will be the same, correct?
Finally, consider the current economy. You did not say where you are, but I am willing to bet you could get the project staffed locally (or even US remote) for less TCO than you think. If they insist you use off shore help, then research carefully and find out the number of oversea projects done by the firm managed from the US. Of that total, how many were on time and on budget when complete. Then contact those customers and get their input. If their references are not glowing consider what the unhappy customers would be saying.
You may be the one that kicks the trend. However, I would be careful about putting your career on the line for it.
By and large the people I dealt with on our Java based project were very polite. They largely came from a VB background, so Java was a stretch. Someone else posted about every answer being "yes", which I found to be very true. Asking questions over a conference call equated to silence. Emails do tend to be taken a little more like orders, especially when the local manager was cc'd. IM was where things became a little clearer. Lots of latent questions cropped up that didn't get asked otherwise. Due to sheer numbers, you will be on their schedule (I was dealing with a 13.5 hour TZ difference...yeah,
I went to your homepage.
What did I find? Your resume?
Nope, just multiple pop-ups trying to install [the evil] gator in my computer!
Don't start blaming everyone else, maybe the real problem is that you don't know how to market yourself!
We (my partner and I) have 20 programmers that work for our very own foreign-owned company in Vietnam.
:-)
Our guys are *good*. They're smart, constantly learning new things and are quite dedicated. At need, they willingly work late hours for special projects and accelerated deadlines.
But one thing that makes our projects work so well is that we think of it (as another poster said) as a **long** commute. One of us is there for about two weeks every month. Houston to Saigon averages about $1000-1100 per flight. It is a *required* business expense for us.
And it's a two-way commute: we're very anxious to get individual staff members over here as soon as we can (lots of visa problems thus far). Not only do we want to get them property indoctrinated with US business practices (!) but we want to show them that a Houston summer is at *least* as unpleasant as one in Saigon.
I'd like to send a big "Fuck You" to your company.
Simple question. Why? America has done more than any other to usher in the era of glabal markets and global business. Someone in India offers the service for less cost, then I say all credit to them. America delegates almost all manual labour to the far east - where are your clothes made? Now they are handing out contracts for skilled work, and because many asian contries have excellent numerate education they are kicking ass. The same will happen in russia when it gets in gear.
The Indian guys we shipped in at $ORK[-2]were a fuck of a lot better than me, and as good as most of the rest of the group. Bear in mind that this was in a research group where the average PhD count was still above one despite two secretaries and a student on work placement. These guys are for the most part _good++_. I don't know where your degree is from, but they probably have two. And cost half as much. Put yourself in the position of the manager - If the project is reasonably atomic and QC isn't going to be a problem then shipping out contracts is a no-brainer.
now watch _this_ get modded to shit.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994
Having done this twice I know how to do this right. Our first experience was using an Indian Java team in Jamaica. We didn't write good specs. We didn't communicate well, and the code drops more often than not had to be re-written by the US based programmers. Generally it was a disaster.
We learned from our mistakes, but there were still disconnects. Our second remote team was based in Eastern Europe. We had established a formal process by then that included HIGHLY detailed specifications. We didn't even start coding until the remote team understood the methods to be used, the arguments and results of every procedure. It was painstaking work, but the code which was generated generally worked right the first time.
In conjunction to very detailed specs I spent every workday morning talking with the individual developers. We worked out details and unexpected problems, because despite having detailed specs to begin with, we didn't anticipate ALL of the potential problems. After each decision was made that was contrary or complimentary to the spec, the design document was updated with the new information. Sometimes we had five revisions a week. We kept our design docs in text mode so diff utilities worked to quickly assimilate differences.
I also spent 6 weeks of face time to work out design issues with new versions of the software. The Eastern Europe team was very sharp and had good questions and provided many novel solutions. Many of the things we encountered during design sessions was not how much we could do with the software, but how much we could cut out. Programmers love to solve complex problems. The challenge was to keep things as simple as possible.
Since we had a US team, we would often create stubs for new sections of the software before sending them overseas for completion. Then the resultant code was integrated back into the main product by US programmers.
Establish formal code review and testing procedures. There were bugs with the code that was found by both the US and Eastern European team during the reviews. We reviewed each others code too.
Establish formal coding standards. Tab stops, logic formats etc. Trying to resolve each programmers individual coding style is a painful exercise that is unnecessary. If you have to be a jerk about it, do it. It will make your life much easier.
Enforce in-code documentation. I can't tell you how many times I got code that worked, but knew that 6 months down the line when we would need to modify it for one reason or another, we would have to learn it all over again. Allow coders only to be clever when they have to be. Clever code for the sake of it is useless and counter productive.
Source control. Source Control. Source control. YOU are the authoritive source. If the remote team wishes to have their own source code server, don't let them do it, or use something designed for multiple repositories. CVS isn't all that good at it.
You will need lots of patience. Don't get ideas about starting something and then throwing it over to the wall to the remote team for completion overnght. It doesn't work that well.
If your team is relatively compact, establish end of day reports. I've used both 'stream of conciousness' logs and things more formal. Send thoughts and ideas to the mailing list for comment. Some idea you think is great has large holes put in it by local and remote team members because of false assumptions on your part, hidden dependencies and other similar things.
Finally, having said all of this, I would have to agree with the other respondents to this post. There are LOTS of top quality programmers in the US who are looking for work, and are HIGHLY motivated to do a good job. I suggest looking closer to home first. The thing that we lost when our company went to a global team was the creativity brought on by the spontaneous exchange of ideas. Each team had it's own collective creativity, but it didn't spill from team to team.
The larger team (remote) began to wag the dog.
'nuf said.
I'm not going to try and just flame you outright because I don't think you deserve it. However:
"Bottom line: process exists to negate risk, so evaluate the risks, then staff and define processes as appropriate. If I were to do it all over again, and I am, I'd invest in a project manager whose not afraid of 36 hour flights and 2 am calls"
This is something that I don't find consistent with doing good work and living well in the process. For those kinds of flights and those kinds of phone calls to exist, you've already lost the battle. You're talking about putting people through tremendously unnatural and costly travel and disrupting people's lives for some BS software work that probably won't even be in use three years down the road? If this were a Moon landing, it'd be different; if this were a once-in-a-lifetime achievement for the participants, then it'd be different. But it's not. It's routine, everyday stuff - and here you are, expecting these earthshaking efforts as a matter of routine. That's how you burn people out and make them hate you.
In my experience, these offshore-development-model projects often wind up with team members who don't know each other and don't know you; you have no real sense of what these people can or can't do. Compare that to the notion of actually hand-picking and guiding a team who you work with all the time, with no time difference and no language barrier; in fact, you can even have a synergy that comes from having a common culture among your programmers (references to towel-carrying, terms like "Pepsi Syndrome," "Slashdot Effect").
I'm sorry, but I just don't consider Herculean acts of cat-herding in order to shave a few bucks
to be virtuous or admirable; you're just perpetuating a let-the-machines-and-the-money-run-me ethic that has nothing to do with having people live comfortable, fruitful lives.