To Offshore or Not to Offshore at Apple?

When I worked at the Apple Online Store we were organized in teams of six.

My team consisted of four software engineers, one project manager (Scrum Master), and one QA engineer. The QA engineer was a permanent part of our team. He was a white-box tester. We wrote our own unit tests and demonstrated scalability with our component tests while our QA engineer verified our logic. He'd look for obvious issues like uncaught null pointer exceptions while digging deeper in search of ambiguous cases like poor security implementations.

New Code Here

Any issues he found in code we were working on in the current sprint were fixed. The rest of the bugs were entered into Apple's bug tracking system (Radar). Once a week we'd meet to prioritize bug fixes. We off-shored the bug fixes to India since it wasn't sexy work. Once it was fixed, we reviewed the code and verified it before integrating it into the main branch.

Bug Fix There

Offshoring bug fixes worked beautifully. Each bug was clearly documented: what really happened vs. what was suppose to happen. I had no idea who was on the other end fixing our bugs but I realized they were intelligent and hard working. However, I could tell they weren't experienced with our technology (WebObjects) or conventions. I've seen the offshore team hard code SQL queries directly into Java. Other times, I've seen objects instantiated simply to access static Java methods.

The beauty of offshoring a bug fix is we wouldn't have to revisit it when it was corrected. Contrast that with coding new features which is under continuous development.

New Code There

Since offshoring bug fixes worked so well we decided to give them a shot at new development. We quickly discovered that was a mistake. The offshore team didn't have enough context to write good code. Their implementations were too brittle.

This problem frequently happens in any coding organization that's offshoring a new development. Without a product roadmap, the offshore team simply writes code to do exactly what you asked for; and no more.

I've never seen specs sent to an offshore team to refactor code. That would be too nebulous of a task. By the time I'd document all the ins and outs of a spec I could have written the code myself. The real problem is that we don't know how our code will behave until we run it.

And that was the crux of the problem with the code written by the offshore teams I've dealt with. They could only do exactly what you asked for, now, without knowing what was coming.

Software engineering isn't an event – it's a process. It's a process of continue improvement and refinement. It's iterative.

Author: Joe Moreno