index.md 2.4KB
title: Collaboration debt slug: collaboration-debt date: 2016-09-18 lang: en chapo: A project is the cumulated experience of a team that will be confident enough to make more experiments.
There is an old proverb (with many variants) that said:
If you buy quality, you only cry once.
I want to make an analogy with development. Let me rephrase it:
If you collaborate, you only lose time once.
Collaboration is clearly time consuming. You have to explain what you did and why you did it that way to at least another person in the team. Everything is questioned. Pairing is even harder given that you are doing this in real-time. So much time lost “just” by communicating you might think at first. It appears that by sharing your knowledge from the beginning, there are now two developers who are able to transmit that information to other collaborators. Event better, the potential of that transmission is exponential, no more single point of human failure (a.k.a. bus factor). Additionally, the quality of your product increases given that everybody is giving his insights.
Don’t get me wrong, sometimes you have to be fast and/or your resources are highly constrained. The thing you have to remember is that you create collaboration debt that will hit you one way or another. You have to be careful not to go too deep in that coding loneliness if you plan to keep that service for a few years. There are two keys for the success of a product: adoption and evolution. If you favor too much the first at the price of the second you’re doomed. Restarting from scratch is rarely a good option and splitting an unmaintainable monolith is incredibly time consuming and will slow down the evolution way too much to be competitive enough.
A product is the cumulated experience of a team that will be confident enough to make more experiments. And these experimentations are the only way to continue to innovate and stay ahead of copies of your product. I can hardly name a single project in my whole career (solo or not) where I was truly confident on the code base. Today, I let go about that and I focus on the confidence within the team to be able to tackle legacy parts which are core features of the product. Chop them down, remove the clutter, transmit the knowledge and iterate. If a team care about itself and communicate enough, the resulting code will hopefully be more maintainable, aesthetic and pertinent.