This is an AMP version of the article, its original content can be found here.

A Distributed Team Delivers Code of Higher Quality

OK, the title is not exactly accurate. I've missed the "can" word. A distributed team can deliver code of much higher quality than a co-located one, and now I'll explain why. Of course, not every distributed team can do that. Most of them can't even deliver code that works, let alone quality code. But if a team—a distributed one—is managed according to the principles I'll explain now, the quality will be much higher than the same team can achieve if co-located. What I'm going to show you is that working in a remote mode, if done right, guarantees higher quality of code. Surprised?

There are basically four simple ingredients to success ... you know what, there is actually one main ingredient, and its name is control. If we want quality to be at some level, we have to enforce it. We can't just declare it; we need to make it high.

How do software teams make high-quality code? Oh, there are many proven methods. First, you need a very modern office where programmers developers sit on cushioned chairs, play table tennis, drink smoothies, and write diagrams on walls. Second, you should buy them many books. Books have to be everywhere in the office, and they have to be about everything from Python and Haskell to Docker, Agile, and lean startups. The more books, the higher the quality of the code they write. And third, you have to pay them well. The more expensive the developer is, the higher the quality he or she writes.

I'm sure you understand that I'm joking. None of these "proven methods" will either guarantee quality or motivate serious software engineers. Quality can be achieved only if it is controlled and enforced. And this is also what motivates programmers best of all—the fact that the quality is so important for management that they find mechanisms of control and enforcement, and they invest in them. Table tennis and lean startup books are not even close to those mechanisms.

So, now let's discuss those four ingredients of quality enforcement, which we practice in our projects:

Thus, as you can see, there is an intentionally created conflict. On one hand, programmers have to close tickets and deliver working code. On the other hand, it's rather difficult to do; because the quality bar is high, there is no room to make compromises, and there is no technical possibility to go around an issue. Good programmers survive in this conflict and manage to deliver and get paid. Well-paid.

And now, to the main point of this blog post—do you think it's possible to build all that in a co-located team? I don't think so. First of all, you won't be able to prohibit informal communications. No matter how many times you ask developers to communicate in tickets, they will resolve most of their technical questions face-to-face. It's inevitable.

Second, you won't be able to pay for results only, because programmers will complain that they are doing a lot of communication in the office that has to be paid somehow. In reality, they will spend two to three hours per day on actually writing code, and the rest of the time will be spent on coffee breaks, Trump talks, and Facebook scrolling. Again, it's inevitable.

And third, people are people. Nobody likes to hit that quality bar multiple times a day. They will complain, and eventually you will give them direct access to the master branch. First, you will give it to the architect, then to a few senior developers, then to a few good friends who you absolutely trust. Then to everybody, just in case. It's inevitable.

To summarize, I believe that co-located teams are just not made for quality programming. For fun—yes. For creativity—maybe. For burning investors' money—absolutely. For quality—not really.