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.
Aug
29
By Erik Dietrich
Is There a Correct Way to Comment Your Code?
Category: Language Agnostic Tags: Clean Code, Comments, NDepend | 50 Comments
Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look at all of the visualizations and metrics that you can get about your codebase.
Given that I both consult and do a number of public things (like blogging), I field a lot of questions. As a result, the subject of code comments comes up from time to time. I’ll offer my take on the correct way to comment code. But remember that I am a consultant, so I always have a knee-jerk response to say that it depends.
Before we get to my take, though, let’s go watch programmers do what we love to do on subjects like this: argue angrily. On the subject of comments, programmers seem to fall roughly into two camps. These include the “clean code needs no comments” camp and the “professionalism means commenting” camp. To wit:
And then, on the other side:
Things would probably go downhill from there fast, except that people curate Stack Overflow against overt squabbling.
Splitting the Difference on Commenting
Whenever two sides entrench on a matter, diplomats of the community seek to find common ground. When it comes to code comments, this generally takes the form of adages about expressing the why in comments. For example, consider this pithy rule of thumb from the Stack Overflow thread.
Jeff Atwood has addressed this subject a few different times.
And so, as with any middle ground compromise, both entrenched sides have something to like (and hate). Thus, you might say that whatever consensus exists among programmers, it leans toward a “correct way” that involves commenting about why.
Read More