Automated Code Review to Help with the Unknowns of Offshore Work
Editorial note: I originally wrote this post for the SubMain blog. You can check out the original here, at their site. While you’re there, take a look at CodeIt.Right, which offers automated code review feedback.
I like variety. In pursuit of this preference, I spend some time management consulting with enterprise clients and some time volunteering for “office hours” at a startup incubator. Generally, this amounts to serving as “rent-a-CTO” for for startup founders in half hour blocks. This provides me with the spice of life, I guess.
As disparate as these advice forums might seem, they often share a common theme. Both in the impressive enterprise buildings and the startup incubator conference rooms, people ask me about offshoring application development. To go overseas or not to go overseas? That, quite frequently, is the question (posed to me).
I find this pretty difficult to answer absent additional information. In any context, people asking this bake two core assumptions into their question. What they really want to say would sound more like this. “Will I suffer for the choice to sacrifice quality to save money?”
They assume first that cheaper offshore work means lower quality. And then they assume that you can trade quality for cost as if adjusting the volume dial in your car. If only life worked this simply.
What You Know When You Offshore
Before going further, let’s back up a bit. I want to talk about what you actually know when you make the decision to pay overseas firms a lower rate to build software. But first, let’s dispel these assumptions that nobody can really justify.
Understand something unequivocally. You cannot simply exchange units of “quality” for currency. If you ask me to build you a web app, and I tell you that I’ll do it for $30,000, you can’t simply say, “I’ll give you $15,000 to build one half as good.” I mean, you could say that. But you’d be saying something absurd, and you know it. You can reasonably adjust cost by cutting scope, but not by assuming that “half as good” means “twice as fast.”
Also, you need to understand that “cheap overseas labor” doesn’t necessarily mean lower quality. Frequently it does, but not always. And, not even frequently enough that you can just bank on it.
So what do you actually know when you contract with an inexpensive, overseas provider? Not a lot, actually. But you do know that your partner will work with you mainly remotely, across a great deal of distance, and with significant communication obstacles. You will not collaborate as closely with them as you would with an employee or an local vendor.
The (Non) Locality Conundrum
So you have a limited budget, and you go shopping for offshore app dev. You go in knowing that you may deal with less skilled developers. But honestly, most people dramatically overestimate the importance of that concern.
What tends to torpedo these projects lies more in the communication gulf and less in the skill. You give them wireframes and vague instructions, and they come back with what they think you want. They explain their deliveries with passable English in emails sent at 2:30 AM your time. This collaboration proves taxing for both parties, so you both avoid it, for the most part. You thus mutually collude to raise the stakes with each passing week.
Disaster then strikes as the end. In a big bang, they deliver what they think you want, and it doesn’t fit your expectations. Or it fits your expectations, but you can’t build on top of it. You may later, using some revisionist history, consider this a matter of “software quality” but that misses the point.
Your problem really lies in the non-locality, both geographically and more philosophically.
When Software Projects Work
Software projects work well with a tight feedback loop. The entire agile movement rests firmly atop this premise. Stop shipping software once per year, and start shipping it once per week. See what the customer/stakeholder thinks and course correct before it’s too late. This helps facilitate success far more than the vague notion of quality.
The locality issue detracts from the willingness to collaborate. It encourages you to work in silos and save feedback for a later date. It invites disaster.
To avoid this, you need to figure out a way to remove unknowns from the equation. You need to know what your partner is doing from week to week. And you need to know the nature of what they’re building. Have they assembled throwaway, prototype code? Or do you have the foundation of the future?
Getting a Glimpse
At this point, the course for enterprises and startups diverge. The enterprise has legions of software developers and can easily afford to fly to Eastern Europe or Southeast Asia or wherever the work gets done. They want to leverage economies of scale to save money as a matter of policy.
The startup or small business, on the other hand, lacks these resources. They can’t just ask their legion of developers to review the offshore work more frequently. And they certainly can’t book a few business class tickets over there to check it out for themselves. They need to get more creative.
In fact, some of the startup founders I counsel have a pretty bleak outlook here. They have no one in their organization in a position to review code at all. So they rely on an offshore partner for budget reasons, and they rely on that partner as expert adviser and service provider. They put all of their eggs in that vendor’s basket. And they come to me asking, “have I made a good choice?”
They need a glimpse into what these offshore folks are doing, and one that they can understand.
Leveraging Automated Code Review
While you can’t address the nebulous, subjective concept of “quality” wholesale, you can ascertain properties of code. And you can even do it without a great deal of technical knowledge, yourself. You could simply take their source code and run an automated code review on it.
You’re probably thinking that this seems a bit reductionist. Make no mistake — it’s quite reductionist. But it also beats no feedback at all.
You could approach this by running the review on each incremental delivery. Ask them to explain instances where it runs afoul of the tool. Then keep doing it to see if they improve. Or, you could ask them to incorporate the tool into their own process and make delivering issue-free code a part of the contract. Neither of these things guarantees a successful result. But at least it offers you something — anything — to help you evaluate the work, short of in-depth knowledge and study yourself.
Recall what I said earlier about how enterprises regard quality. It’s not as much about intrinsic properties, nor is it inversely proportional to cost. Instead, quality shows itself in the presence of a tight feedback loop and the ability to sustain adding more and more capabilities. With limited time and knowledge, automated code review gives you a way to tighten that feedback loop and align expectations. It ensures at least some oversight, and it aligns the work they do with what you might expect from from firms that know their business.