Cost of connection, Group intercommunication formula: n(n − 1) / 2

“The Mythical Man Month” – Fred Brooks, 1975

Like most people I am currently working from home. The Corona pandemic is upon us and everything has changed. When we emerge from these hard times, we will see a new normal. I hope this new normal can also be better.

Because of the situation, our development teams are now 100% distributed, an unwanted but interesting experiment to study. Suddenly we are more equal, there’s no onsite and offshore, everyone is alone.

This post is about offshore development, or rather some learnings and “don’ts” from my own experience from the past seven years, through different setups.

First, what are the main drivers for choosing an offshore development service? I think the following are the most common:

1. Cost savings
2. Outsourcing functionality
3. Recruitment difficulty

These are all fair aspects but you need to think twice and wisely when selecting areas suitable for offshoring.

Here are four anti-patterns* that I have discovered.

Anti-pattern #1: outsourcing development of business differentiators

There’s IT and there’s IT. In my experience, areas that can be defined by standard processes and require limited domain knowledge might be good candidates for offshore services. This can be general user support, client platform support, basic application support. Other good candidates are non business-critical applications with a low change demand.

However, for your business differentiators: don’t do it! Don’t waste funding on external intellectual capital. Build competence, experience and ownership in-house.

Anti-pattern #2: believing you can solve internal weaknesses by outsourcing

So, you decide, regardless of anti-pattern #1, to develop your business-critical products offshore. Bad idea! I have observed a mindset believing offshore teams require less leadership from the organisation: nothing can be more wrong. All internal organisational flaws and conflicts will grow larger, poor leaders will make even more poor decisions and weak architecture will not magically be repaired, rather technical debt will grow.

There are no shortcuts: identifying and solving organisational root cause problems requires ownership, tough decisions and hard work.

Anti-pattern #3: regard software development as a service

It’s very convenient to define your applications’ lifecycles in a service agreement. And yes, this can work, if keeping a status quo is good enough and your ambition is to never get blamed for causing problems or not following agreed-upon processes. But if instead you want to make a difference, this is not the way to go.

How do you articulate in a contract that you appreciate curious, limitless and challenging explorers? That it makes you happy when developers suddenly implemented a new tool, a new framework or just killed a bunch of legacy code? That quality is built-in from the start in everything we do? This is software craftsmanship, with curiosity, continuous improvement and a strong pride in what you do and how you do it.

With the #1 main driver being cost reduction, services are defined good enough at the lowest cost and by doing this, software craftsmanship and quality are lost.

Anti-pattern #4: accepting large and unstable teams

Finally, I just want to emphasise two common tricky characteristics of offshore organisations: over-specialised roles and high staff turnover.

In “The Mythical Man Month” the expression cost of connection is defined as:

Group intercommunication formula: n(n − 1) / 2

showing how communication overhead within a team will grow exponentially with its team size. This fosters efficient small teams with t-shaped team members.

However, in offshore organisations, I have observed over-specialised roles, requiring team sizes of up to 15 members. The reason I have found is the strong career path model where there is a clear hierarchy between all the different roles. The strong hierarchy of the offshore organisation also gives teams little responsibility and autonomy.

The constant career ladder-climbing leads to a very high staff turnover, leaving the team in a constant stage of forming. The effect of this is an endless reinvestment in training and will remain your daily challenge.

***

And the experiment? Well, of course we make it work, but nothing compares to sharing a coffee machine 🙂

*An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.