"I would describe my codebase as _____ and _____."
If you had to pick a pair of everyday words to describe the nature of your codebase, what would they be? Take a moment and fill in the following blanks.
"I would describe my codebase as ______ and ______"
Now, answer a similar question about your ideals:
"I would describe my ideal codebase as ______ and ______"
Chances are, your responses differ quite a bit. Of the 15 developers i polled before writing this post, only 1 had a word appear in both of their current and ideal answers.
Making sense of the results
So what do these words tell us? Taken in a vacuum, very little. The real value of this exercise is realized when the answers to it are collected among a team of people.
When i asked a bunch of current and ex coworkers their thoughts, some pretty clear trends arose. Every word expressed some degree 2 ideals: ease of working on a codebase and enjoyment when working on a codebase. I tried illustrating this relationship in a laughably unscientific graph.
Arguments about the placement of individual words aside, if these results came from a single department, it would be clear that a lot of work was left to be done improving the culture of the codebase.
The culture of a codebase
"Culture? Of a codebase? What?", you rightfully ask.
I say yes. Codebases have a culture imprinted in them by the people who build it. It may be a culture of speed, or risk taking, or safety or something else entirely. But it is inevitable that a the dynamics of a team's coders, development process and customers will result in a wholly unique, culture-rich codebase.
So what is the culture of your codebase? Run this exercise with your team and consider the results. Try graphing them on similar axis to the ones above. The resulting terms should highlight what members of your team value in code, be it ease, enjoyment, simplicity, etc.
Once you have them out in the open, they can become a factor in tech decisions and code style. If "simplicity" is a collective ideal of the engineering team, it promotes holding one another to a standard of reducing complexity. This won't be possible all the time, but it begs justification before complexity is injected in the future.
A measure of enjoyment
If your team is similar to a couple of my ex coworkers, one of the ideals will be that a codebase is fun. I cannot agree with this more. Too often we attribute a "fun" codebase with the injection of some bleeding edge framework or language. While this may bring short-term fun, it generally serves as a massive injection on complexity, leading to later woes.
Instead, i encourage you to find other ways to increase the enjoyment of a codebase. One of our methods has been informative but amusing code comments. There is a surprising morale boost when you are reading through a code file and happen upon a comment that leaves you laughing. Small pebbles of joy can do a lot to keeping a codebase fresh to its maintainers.
CI: continuous improvement
Perhaps the hardest thing about coding a system is making it better over time. One dev's response about working on their codebase captured this perfectly:
"Well, all of my code is awesome. Until it isn't. Which doesn't take that long."
Amen, Chad.
We should strive to continuously improve our codebases as we work on them. But what exactly does that mean, to improve a codebase? Turns out that answer is different depending on who you ask.
First, our team needs a collective understanding where our codebase's culture is and where we want it to go. Part of that answer will be found in the difference between where you say your codebase is and where your ideals are. Part of that answer may be verbalizing the culture of your codebase.
tl;dr: Our time working in a codebase is defined largely by the culture of that codebase. In order to improve that culture, we must first define and measure it.
