by Andrea Goulet

Treat your codebase like a house. Don’t bulldoze it just so you can remodel the kitchen.

My dad is a self-described contrarian and eccentric. I love that about him. He doesn’t ever do something because that’s the way you’re “supposed to.”

He’s also incredibly driven and energetic. He’s a fixer. If he sees a problem, watch out. If it aligns with one of his passions, he’ll put all of his energy towards finding a solution.

Several years ago, he turned his focus towards making his house as efficient as possible. My parents had sold the house that I grew up in and had bought a small ranch-style home in a rural suburb outside of town.

Since my dad is looking toward retirement these days, monthly expenses are big on his mind. One night at dinner, he proclaimed that he wanted to figure out how to reduce his electric bill to its lowest point.

We all knew what was coming: a charged focus on solving this problem that would serve as his outlet for the next several years.

My dad loves to research and implement. He’ll spend hours and hours online hunting down that perfect solution to his problem. He loves being the “fixer upper” person, and spends his weekends knocking tasks off his punch list.

One weekend, it’s replacing every light bulb in the house with a certain LED light that emits the lowest voltage. Another, it’s installing a wood pellet stove to heat the living room so he can reduce the need for the central system. Upgrading windows, creating his own bio-diesel for generators, insulating the crawlspace, adding solar panels, the list goes on and on.

Over the course of a year, he gradually made his house efficient, to the point now where he is almost generating a surplus of electricity. “Won’t that be great,” he says. “When the electric company is paying me?”

This is how I grew up. House maintenance was an integral part of life. Every weekend, we had some kind of chore to make the house better.

So when I came to software, I was surprised to learn that maintenance is often an afterthought.

For years, the culture of the software industry has been to reduce the team to a skeleton “Operations & Maintenance” crew — which was completely separate from the team that created features and shipped the product. This O&M team often got little respect, and were treated as second class developers.

There was a clear caste system for developers. The people who tested and improved existing code were on the bottom.

The “cult of re-write” began to take hold. Developers who thrived on new construction — rather than continuous improvements — were making the case to executives and investors that the only way to solve the problem was to bulldoze the codebase and start over.

My business brain, coupled with my experience growing up, always saw this as a tremendous waste of resources.

I envisioned my dad, putzing around the house on the weekends tackling one of his projects. How would he feel if he encountered a problem? Would he bulldoze the house if he wanted to remodel the kitchen? Of course not! But we’ve convinced ourselves that’s the right thing to do in software.

Instead, I advocate for a different model. Let’s focus on remodeling our software, like my dad remodeled his house. In this model, we focus on the fixes that will bring the biggest value first. It’s impossible to get everything done in one weekend. Rather, it’s about slowly transforming the codebase to become as efficient as possible.

Here are some ways we can look at remodeling:

Design = UX/UI
Sometimes, you get sick of looking at that mustard-yellow toilet and bathtub. What were they thinking?

Aesthetic improvements can go a long way toward helping us feel comfortable. The same goes with software.

A nice design refresh can often add a lot of value to an application.

Daily Chores = Writing Clean Code
We need to take out the trash, do the dishes, and clear out clutter. If we don’t do these daily maintenance items, we’ll be in big trouble later.

In software, this means writing intention-revealing code and using source control to document our rationale.

You can only sweep bad code under the rug for so long before it starts slowing down your entire system. Writing clean code doesn’t take much longer than writing dirty code.

Re-Organizing = Refactoring
Who would have thought that a book on decluttering your home would have been a breakaway bestseller?

In her book, The Life-Changing Magic of Tidying Up, Marie Kondo shares her strategies for removing items from a physical environment, and how the act of deletion is critical to feeling calm.

The same principle applies to code. We need to reorganize and delete code regularly so that what remains is a pleasure to work with.

Tearing Down Walls = Unknown Unknowns
There are some elements in our houses that are a pain to change, and therefore get expensive to change when we finally gather the will to tackle them.

These are often the hardest to estimate, too. Think about the home improvement shows where they have to tear down walls. Surprise! Bugs like termites — or someone else’s poor craftsmanship — can derail a project.

You thought you’d be getting that clawfoot tub, but instead, you have to spend money replacing your subfloor.

This happens with software, too.

Efficiency Improvements = Continuous Delivery
My dad focused on making his home as energy efficient as possible through replacing windows, light bulbs, and updating the heating system.

In the same way, we can look for ways to reduce the energy it takes to get software from the developer’s hands into production.

Environment setups, deployments, and testing are all perfect for this type of optimization.

Open Floor Plans = Monoliths & Microservices
Fifty years ago, there was a trend in home building to have discrete rooms. People wanted privacy. Now, our needs have changed and in almost every home improvement show, the designer will make the floor plan more “open.”

The same trend is taking place in software, where large codebases (monoliths) are giving way to smaller ones that are more integrated (microservices).

Locking Your Doors = Security Concerns
Imagine if the lock on your door had an expiration date. Every two years, unless you upgraded, it would disappear, and people could walk right in and take what they wanted.

The vast majority of software-related security breaches don’t happen because we lack some Mission Impossible-style security system. They happen because we’re negligent to language and framework upgrades, which eventually make our codebases vulnerable to attack.

If we approached this with long-term investment-first thinking, we could continue to get value out of a software application for years to come. It’s not free, but if approached in the right way, it can be incredibly rewarding.

So what do you think? Do you remodel your software, or are you still in the re-write camp? Let me know your thoughts in the comments.

Thanks for reading!