Every Team is Distributed

I was reading The Rules of Attraction: Location on Mark Seemann’s blog when I had a thought: Every Team is Distributed.

If you’re Github or Stack Overflow then you have a global workforce drawn from the top developers across the entire planet. This didn’t happen accidentally but as the result of a deliberate business decision to support remote workers. It is obvious that you have a distributed team.

If you’re a consulting firm writing software for a major corporate that is used nationwide by the various branches of the company, then you might be a distributed team, depending on whether your support staff are located close to your users.

But what if you’re a team of three developers who sit next to each other developing bespoke in-house applications? If the entire team is within earshot and all the users are in the same building, surely there’s no need or desire for a distributed team.

What’s missing is a consideration of time.

In his blog post, Mark gives a list of examples - two of them are (or might be) about the passage of time.

• Why did we build our own ORM, instead of using Entity Framework?
  Uhm, yeah, there was this lead developer, Rick… He’s no longer with the company…

Why did rick roll his own ORM? Perhaps Entity Framework didn’t exist when the project started, perhaps the need to integrate with the Oracle based payroll system means that Entity Framework wasn’t sufficient or perhaps he was an egotist with his own term for not invented here syndrome. Who knows.

• Is there any way to prevent the back-office developers from accessing our database directly?
  Probably not, but let’s have a meeting!

Why did the back-office developers get direct access to the database in the first case? Was it a side effect of the reporting tool, a decision made to expedite resolution of production issues or the result of adroit political wrangling by our old lead developer, Rick? Again, who knows.

In both cases, the problem is one of communication - and not communication that can be resolved by getting the relevant parties together in the same room for a dreaded meeting, because those parties aren’t separated by distance but by time.

These are not isolated issues.

Every team is distributed in time.

Developers - and other team members - come and go, so the team changes over time. Average tenure in many IT roles is between two and three years and is trending lower. Even if you have a stable team who has worked together on the same system for ten years, you still have to consider things like retirement and rogue buses.

Even a “team of one” is distributed in time because the person you are today is different from the person you were several years ago. New skills are gained and memory fades - things that were obvious to the you of 2012 might be mysterious to the you of today and things that are easy for the you of today might have been impossible for the you of 2012.

If you’re relying on co-location as a way to convey knowledge, you’re setting yourself up to have problems in the future. Some examples…

… those business rules you’re automating that everyone on the team now understands inside-out and back-to-front? After a couple of years of successful automation, no-one will really remember what those business rules are or how they work.

… a business representative, a subject matter expert, assures you that the business will always be doing things in a particular way. A manager leaves, a replacement is hired (or promoted), policies change or new legislation passes, and those processes that were locked in stone are suddenly very different.

… your automated deployment pipeline, the one that has successfully built tested and deployed releases every day for the past eighteen months? If the woman who built and maintained it suddenly gets an offer she can’t refuse and takes another job, how long will it continue to tick along without any attention?

… after thorough research, you settled in 2009 on a particular technology stack for your new project - a language and platform, an architectural approach, a data persistence strategy. All of the system constraints are accounted for, including the needs for cross platform transaction management, systems integration and records management. When someone asks your successor in 2016 why the system wasn’t built with micro-services instead, what will they answer?

The common theme for these examples is the way that the passage of time can remove access to knowledge that was once well known.

Fortunately, the same tooling that provides good support for physically distributed teams can also support temporally distributed ones, giving us another reason to adopt them.