Software Remodeling

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 towards retirement these days, monthly expenses are big on his mind. One day 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 makes 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 that 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, with people who made improvements to and tested the code 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 with some sort of project. 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 to 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. None of this takes a lot of time, but you can only sweep bad code under the rug for so long before it starts slowing down your entire system.

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 are expensive when we decide 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

Just like my dad focused on making his home as energy efficient as possible through replacing windows, light bulbs, and updating the heating system, we can look at 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, 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 security breaches don’t happen in software because we lack Mission Impossible style security systems, it’s because we’re negligent to language and framework upgrades which make our codebases incredibly vulnerable to attack.

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

What do you think? Do you remodel your software or are you still in the re-write camp?