☕ Welcome to The Coder Cafe! Today, we will discuss the concept of organic growth vs. controlled growth. Get cozy, grab a coffee, and let’s begin!
A few months ago, I was in a meeting discussing the state of a codebase and heard myself say:
This codebase has grown organically.
After reflecting on my own words, I began questioning myself: I don’t even know what organic growth really means and whether it is ultimately positive or negative.
Discussing the concept with various colleagues, I noticed we had different interpretations. I also created a poll on X that went viral (#irony), showing that most people see organic growth as something positive.
If Perplexity is correct, the term organic growth was used first in Bushido: The Soul of Japan, published in 1899. The author, Inazo Nitobe, describes Bushido (aka the way of the samurai) as something that developed through organic growth rather than being the invention of a single person or the result of a single event. In other words, Bushido emerged gradually over decades and centuries as a collective experience, not the product of one individual.
It’s easy to draw parallels with the many codebases we maintain at work. The older the codebase and the more developers it has had, each with their own vision of how the code should look. Differences in perception arise from factors like developers’ varied mental models based on the parts of the code they know best.
Developers come and go, making changes, introducing biases about what the future should be, and after years, the codebase reflects hundreds or even thousands of such incremental changes.
This is organic growth in software: incremental delivery driven by agile methodology that shapes codebases, often in a bottom-up manner.
So, is organic growth good or bad? Let’s use the garden metaphor: imagine a public garden where anyone can plant whatever they want and wherever they want. Over time, sure, it’s colorful, but there’s little harmony, with a lack of overall guidance or direction:
Now imagine we control what can be planted and where, and periodically review and rearrange what’s growing. Our garden will likely look harmonious and well-maintained:
In my opinion, organic growth carries a somewhat negative connotation, implying a lack of direction, with systems growing out of ad hoc solutions and quick fixes rather than intentional design.
So, how can we move from a messy garden to a harmonious one? By transitioning from organic to controlled growth.
Controlled growth is the deliberate and reflective process of evolving a codebase. With controlled growth, we should also embrace progress that is not always perfect but consistently guided by shared patterns and standards, fostering sustainable, manageable, and harmonious development over time.
Here are five main rules for controlled growth:
Be consistent. Follow agreed conventions and standards to build maintainable and predictable codebases. Many standards aren’t explicit, so strive to follow even the implicit ones. For example, if an entity is consistently named X, don’t be a cowboy and name it Y; stick to X.
Plan ahead for large changes. Think strategically and collectively about big transitions such as significant new features. Avoid chaos and technical debt by breaking ambitious changes into smaller phases, communicating plans early, and leveraging documentation assets such as design docs (see Explore Further section).
Hold regular retrospectives. After major development milestones, gather the team to review what went well and what could improve. Retrospectives foster a culture of learning and continuous improvement, a strategic pillar of controlled growth.
Apply the Boy Scout rule. Frequent changes are inevitable and often rushed under pressure. Remember: “Always leave the campground cleaner than you found it.” When making a pull request, spend a little time refactoring small bits, cleaning legacy code, removing dead code, or renaming variables. This keeps the garden harmonious over time.
Build a team where everyone shares responsibility and speaks openly. Controlled growth shouldn’t fall only on tech leads; it should be everyone’s job. When all team members feel heard and share responsibility for the health and quality of the codebase, the team grows on a stronger, more sustainable foundation.
❤️ If you enjoyed this post, please hit the like button.
💬 When you say a codebase grew organically, what do you mean?
📚 Resources
More From the Programming Category
Tidy First? // We already discussed organic growth in this post.
Hi Teiva, any thoughts or readings recs on handling a codebase that has already grown organically to the point of chaos? It's easy to see the benefits of a harmonious codebase, but sometimes I feel like I'm trying to pull out the weeds in a jungle, so to speak.
Balancing consistency with re-writing bad patterns is quite tricky!