I had written before that most start-ups are expected now to work with remote development teams in order to lower their burn rate. But what about those other start-ups? The ones that are six, seven or more years old and still call themselves a start-up. In part they are doing this to set and continue a certain mindset; we move fast, we’re lean, not a lot of bureaucracy to get things done, etc. So what about this type of start-up, what are they interested in? As often as not they may keep everything in-house, thinking they move too fast to work with remote developers. They may have tried outsourcing (either onshore or offshore), but it failed. Sometimes I am hearing that they tried it 3, 4 or more times and every time it has failed. But they are still interested to try it again. Can give them credit for wanting to try it again, but it is interesting to dig in to the reasons they give for the failures, in order to determine what not to do next time. Let’s examine a common reason given for failure and see what a start-up of this type can do to avoid this issue in the future.
One reason I have heard for why outsourcing has failed is “bad code”. Now I can see that you do not want, and should never settle for “bad code”. As a customer, you should never settle for code that cannot later be easily maintained, that is not architected correctly, etc. Also, of course you have a right to look at the code while it is being developed; it is your code that you are paying for. Certainly that should never be an issue. Often, however, when I ask exactly what was so bad about the code, “Why was it bad?”, the answers sometimes become a bit vague… I would expect to get answers which were more concrete, something like, “They wrote the app so that the entire survey was loaded in to memory, therefore the app could not easily be run on different telephones which had less memory.”, or something similar depending on the platform or the type of application in question. Or to hear a reason such as, “The developer did not document the code correctly, or at all.”
However, a more typical answer I hear is that it was just bad code (not from everyone of course, but often enough). Here in lies the problem I believe and I think you can see it too. If you can’t define exactly what you didn’t like about it or what was not done correctly, then how would the developer know exactly what you wanted. You may argue that you should not have to tell the developer to use common acceptable standards for the language they are developing in, or to comment their code, etc., with that I would definitely agree with you. But if that were really the problem, then that is what I would hear from VP’s engineering or CEO’s of companies as the reason why outsourcing did not work for them in the past. But I do not hear that, I just hear, “the code was bad”, which leads me to believe there is something else behind why it was bad.
So how do you get around this the next time you want to work with remote developers? There should definitely be a discussion of what you expect in the code, with the developers. Telling them you are going to be looking at the code is one thing, well they should expect that you will look at it since it is your code and it will be delivered to you. But being more concrete as to what you expect as far as: official coding standards to be followed, if your company has its own standards that you want followed, your expectations for code documentation, etc. Another suggestion would be to include as part of your weekly deliverables, or once every couple of weeks (at least at the beginning of the project), code reviews. Have the developer explain why they wrote something in a certain way. Also, if you expect architecture to be done as part of the project, or if you are not providing it, have the developer document the architecture and send it to you for your review, then have a discussion on it before the developer goes forward and starts writing code. Following a few simple methods of getting to the goal of having good code, can eliminate the “bad code”, and the frustration that goes along with it.