This page looks best with JavaScript enabled

The Outsourcing Trap

 ·  ☕ 6 min read

There are plenty of outsource shops who test their luck by selling cheap labor. The strategy is nothing new in a capitalist society, but the outcome can be devastating when it comes to software industry. It’s one thing when you hire a cashier, worst thing that can happen is they incorrectly scan some items, and your shop loses $100 in revenue. It’s a totally different situation when your software doesn’t work, and your client who paid 100s of millions of dollars wants their money back. What took years to build and become rich, can get you bankrupt in months.

It’s a trap!

Outsourcing is a trap most big and mid size companies fall into. Advising to outsource is like advising someone to walk on a rope. Sure 1 of 100 would be careful and do it right. What about the other 99? After 12 years of experience as a software developer and last 2+ years working remotely as an onshore agency consultant (before COVID), I have not seen good outsourced code even once.

Best case scenario - after weeks of code reviews, a dozen of partial rewrites and advise from senior developers it’s still “barely OK”. Would be a lot better if that review time was spent on rewriting the whole thing from scratch. One notable example, I was asked to fix a bug in about 3 pages of spaghetti front end logic. The outsourced team from India spent about a month combined to initially write it and then fix all bugs that were constantly popping up. After about 1 hour looking into it (never seen the code or requirements), I deleted everything and wrote one line that did the same thing. Yes, one line and the bug was never reopened. Let’s talk about cost savings…

Rates comparison

An offshore software shop in India will likely charge you around $30/hr per developer. An average US based standalone contractor will be in $70-75/hr range. An agency contractor will be in $100-120/hr range, or higher if they are really good. As a baseline, we can roughly say that an onshore developer is 3 times more expensive in raw cost, relative to offshore.

Now consider the need to change and/or rewrite the code. In my experience, the majority of headache comes from incorrect assumptions and taking quick and dirty shortcuts in order to meet deadlines. So, you spend $90/hr once, or you spend $30/hr first, blow the deadline, and spend $90/hr to rewrite. Oddly enough, at that point money becomes a secondary factor. More important is that the right code takes away all after hours and weekends spent on customer calls. With bad code, you will have lots of those. Or you had them already. Talking about the quality of your private life as a software development manager, lead developer, VP of development and so on.

Prevent awful code by design

So, when we talk about offshore code quality, “awful” is not an outlier, it’s a statistical average. Why do they get paid? Decision makers don’t completely understand how to verify the outcome. Correct code is not just something that fulfills business requirement (which can be verified by QA). Correct code is something you write once and forget about it (see SOLID).

But it’s impossible to write code once and have it work for 20 years, right? Wrong, it’s in fact how the majority of software written in C++ used to work. One developer would write a whole system from scratch within a few years, without bugs, without performance issues. Without agile, standups, scrum boards, all that junk. Want proof? Find a software developer who has been doing their job for 40+ years and ask them. I did. It’s the world we forgot ever existed.

Back to offshore pitfalls. Problem here is that really good code only shows within a few years’ time. Usually long after a typical offshore contract is fulfilled. And guess what - the offshore folks know it perfectly, that their work only needs to live long enough to get paid. They often undershoot and end up fixing hundreds of bugs shortly before the cut-off. This is how you know it. One developer spends overtime fixing bugs 1-2 months before delivery, and another one tends to chill out, because his/her code “just works”. Make sure you understand which one of those is lazy, and which one is talented. 99% of managers make the wrong decision.

How to prevent the upcoming weekend chaos? Look at high level metrics rather than code. Understand that failure in software development is actually predictable with a high degree of certainty. Know which metrics are important - including code metrics, Jira metrics, database metrics etc. Put a very technical person in charge of this effort, and have them gather and analyze as much as possible high level information about code. A good candidate for the job would be your senior architect or principal developer. A bad candidate would be a random senior developer who will eventually give up at the onslaught of never ending code crap and let it slide.

What to measure

There are a few basic code metrics that can help evaluate code at high level, without having to read it line by line. I would, however, make a correction to maintainability index ranges for good code. Microsoft insist that anything between 20 and 100 is maintainable. Let’s make it 60 to 100, where 60 is borderline okay. Good code is 70+ and anything about 80 is excellent, and probably something you will never see on the job. Code below 60 is either junk, or will become junk in a few years’ time.

If you want more metrics, configure your own metrics, see metrics on graphs and in tables, you can check how NDepend folks are doing it. Not an affiliate link, they are just a good example of being passionate about code metrics and quality.

Better than outsource

The advice I would give to companies considering outsource - hire top developers, pay them top dollar, respect their work and invest in writing/maintaining company’s framework. Here is another real world example that shows the importance of having an in-house rapid development framework. I was given 3 months to implement 26 pages of requirements in a word document (all text, no pictures). I did it in 5 hours, with 4 of those spent on reading the document and looking at various places in code. Nothing was reopened and no bugs. Do you still need to hire cheap 100 developers who would blow the 3 month estimate and barely finish in 6 months?

See also:


Victor Zakharov
WRITTEN BY
Victor Zakharov
Web Developer (Angular/.NET)