Too many people think that some magical transformation will happen when they outsource their code development. The air will smell fresher, the water will be cleaner, and suddenly you will meet all your budget and milestones. Well, as my uncle would say “a’int gonna happen”.

Outsourcing is a tool. Nothing more and nothing less. And like any tool, it is only as good as the people who use it. For an example, take my tennis ability. I once bought the same racquet that Andre Agassi used to win the Australian Open. For some unknown reason, when I used that racquet, still sucked at tennis. ( Must have been a defective racquet. )

Which leads me to my newly favorite quote from Guy Kawasaki.

Somehow we’ve got it in our heads that every programmer in India is good, fast, and cheap, and every programmer in the United States is lousy, slow, and expensive. My theory is that for version 1.0 of a product, the maximum allowable distance between the engineers and marketers is thirty feet.

Which then leads me to two of my favorite rules you need when you are outsourcing.

Keep your idea people close.
Outsourcing the grey matter parts of a company is not possible. If you are going to do that, why not outsource the entire company. Now if your PHB wants to pack your entire company into a shipping crate and send it on a slow boat to Elbonia, you have a lot more to worry about than this article you are reading right now.

The further your creative people and decision makers are from the people cutting the code, the more generic the code must be given the same amount of management. Note, I said “amount of management”. This is of particular importance to a certain manager who shall remain nameless. Dave. Here is a general rule of thumb, if you cannot manage a programmer who who is sitting about 10 feet away from you, how can you manage a programmer that requires a 26 hour flight , four bad airline meals, and three plane changes to have a face-to-face meeting. Dave.

Bad Code can be written anywhere.
Just because something is written overseas, does not mean it is good. So when we get things from overseas, we have to treat the code like it just got off a boat full of bird flu infected chiropractors from Hong Kong. When you get the code back, you should test it with your in-house people. That is a job that CANNOT be outsourced. Trust me on this one, if you allow the people writing the code to do their own QA, the QA will start to slip when the going gets tough. So check the code yourself, and let the people writing the code know you are watching.

Use tools to check the code coming back. There are several tools like Coverity, McCabe QA and Polyspace for code coverage and static analysis. Coverage and static analysis tools , if not overused to the point of being dogma, will find defects. Your offshore coders are usually making sure that the code they write can make it past the acceptance test. You really do not want the coders doing the coverage tests. Coverage tests are easily abused and they may lead the coder to start writing JUST to make the coverage analysis clean. The reason we have acceptance tests is to check functionality, the reason we use code coverage is to find defects in the code. Finding the line between the two is sometimes not an easy thing, and it is best done at home.

Now , just because your coverage tool says that your code is defect free, does not mean you can be 100% sure it is ok. Code analysis tools have to keep the number of false positives low so developers are not sent chasing down non-bugs. It may not be perfect, but is is good start.

So how does this relate to my Guy Kawasaki quote? Well, the moral of this story is that when outsourcing, remember that it is a tool that produces code that you need to design and manage just like code you write in house. Design in house and outsource the code you want. When it comes back, quarantine it, run your code analysis , run the acceptance tests and THEN let it in to your house.

As a footnote, for those of you who seem to relish in finding spelling errors and grammar errors, I intentionally leave them in for your reading pleasure.

10 Comments »