Stop Rewriting Everything: The Hard Truth About Collaborative Engineering

Throughout my professional life, the most difficult engineers I had to collaborate with have had one thing in common: they find it hard to expand on what has been already done. You almost know them at first glance. They come across code that is functioning well and that just does not fit their style and the first thing they think of is to rewrite it rather than to improve it.

Refactoring takes up days, but when questioned as to what changed, there is little mention of metrics or quantifiable benefits. Performance, stability and build times are not improved. Rather, it is a subjective reason: the code is cleaner, or it is now more maintainable. But behind, the fact is that the codebase is no better it is just that different.

This behaviour deteriorates with time. Each and every handoff causes a rewrite. Technical debt is not something that is paid off, it just decays into a new variety of debt depending on the style choice of another. The new engineers come in and inherit another codebase that has been cleaned up only to continue the same process.

What is most interesting is that such engineers mostly favor green field projects. Blank slates grant them authority and they do not have to learn past judgments. It is ambition, but in the real sense it is avoidance, avoidance of adaptation, teamwork and operating within the established confines.

Unlike that, great engineers do something much more valuable, they adapt. They also take time to learn the current trends, the past compromises and the architectural decisions. They develop systems in a considered manner and only refactor where there is a problem they are trying to solve rather than because they do not necessarily agree with choices of style.

A skill of working on a code that was not written by yourself is not only a skill but also a precondition to work on the real software team. The majority of meaningful software is created through a collaborative effort and in a step-by-step fashion and with sensitivity to the base already present. It will not help to write a codebase better, just because writing it down again will be a way to inflate ego, but it will only slow a team down.