I have worked with a ton of kinds of codebases throughout my career so far. Some of them are pleasant to work with, and most of them are the opposite. But it’s always bugging me on why are some of them are really wonderful to work with and some of them are not?

The Phases

Every single interaction that you will have with some form of codebase will fall into one of these categories:

The Reality

Every single one of us are hoping that whatever phase that we encounter on a codebase, it would be pleasant to work with. We hope that the codebase is well-structured, well documented, well tested, and well performed (assumed deployed properly).

But as the reality kicks in, each stage has its own problem.

An early codebase might be well-structured and performed since the number of features and integrations are quite small, but often time it’s not well documented and tested.

A little-bit more mature codebase (Mid-journey encounter) is often time lacks all of them 🤣. The features and integrations are growing, but mid-size team will often times are ruling out the tests, documentations, and the performances.

A mature codebase is often already well documented and tested. But since a ton of hands are got in touch with the codebase, a mature codebase is often difficult to work with since the consistent structure are not there anymore. AND, the documentation provided is not helpful at all (it’s there, but it doesn’t help).

Then, How To?

Among all of those three phases above, the Mid-journey encounter is critical. This is the phases where the habits, structure, conventions are formed. This phase’s development should be opinionated. Opinions are formed by all the team members, discussed, agreed upon, and followed by everyone.

Every changes that would be made to the codebase should be created based off of the agreed upon opinions and strictly reviewed based off of the agreed upon opinions.

Why Not in the Beginning?

In the early life of a codebase, there are few cases:

Published on: