Choose your hard: The maintainability load curve


Maintainability isn’t about what’s easier to write or do today. It’s about our cognitive load and what is easier to live with tomorrow.
Maintainability isn’t something we should take for granted, yet it goes around achieving the least amount of real estate in the minds of engineering teams. Of course, some of you may say: “well, Carl, I advocate for fast follows, tech debt management, and at least some prioritization on focusing inward”. I’m not one to beat a dead horse, so let’s archive those thoughts and focus on what’s in our control—making a case for our sanity.
Scenario 1: You were “too tired” to clean the kitchen.
You wake up the next morning, coffee in hand, only to find dirty pans, crumbs on the counter, and sticky stains that have hardened overnight. Cooking breakfast takes twice as long. You grumble, but you did technically save time yesterday.
Scenario 2: You actually put away your clothes this time.
It’s 7:55am, you need to be out the door by 8. Your shirt is right where it should be, not buried under yesterday’s pile. You shave 5 minutes off your morning scramble, and more importantly, you don’t start your day a little annoyed.
Scenario 3: You make sure everything has a home.
Everything has its place: kitchen utensils, jackets, lint rollers. The payoff is subtle, almost invisible. But the fact that your brain never has to run a search query for a missing item? That’s the real dividend. You’ve shifted the burden from “‘future you” into today’s system.
The Engineering Parallel
Maintainability works exactly like this. You can defer cleanup. You can do the bare minimum. Or you can build an environment where the default state makes life easier for everyone who comes after you (including future-you).
Each choice is a tradeoff. But there is no “free” option. You are always choosing your hard.
In scenario 1, there was less work now, exponentially harder later. Debugging through sticky code paths at 2am is the engineering equivalent of scraping dried food off a pan. Not fun. In scenario 2, you save future-you some effort by doing some light cleanup, but inconsistencies still leak. This is the “fix only the bug you touched” school of thought. In scenario 3, the cost is upfront discipline, standards, and often pushback when deadlines loom. But the payoff is compounding: code reviews go faster, onboarding is buttery smooth, and systems evolve without collapsing under weight.
In short: maintainability isn’t free. With each action or inaction, that choice becomes easier and easier to make for your brain. It’s a conscious choice to move effort from the future into the present. And just like the kitchen or closet, the more you systematize, the less “hard” you’ll feel day to day.
Maintainability Load Curve
Parameter | Low Load State | High Load State |
Cognitive Overhead | One person can grok the flow quickly | Multiple engineers spend days reconstructing context |
Error Propagation | Bugs are localized and recoverable | Small bugs ripple through multiple services |
Onboarding Time | New hires commit safely within a week | New hires take months to contribute meaningfully |
Change Resilience | Features evolve without breakage | Any change feels like a game of Jenga |
Debug Time | Logs/tests guide you straight to issues | Debugging is archeology |
Consistency | Patterns are recognizable and repeatable | Every function feels bespoke |
Maintainability load is real. If scalability defines how systems respond under stress, then maintainability defines how people respond under stress. And unlike traffic spikes, there’s no pager to warn you when it’s too late.
So, if you were to take anything from this, remember this quote:
Clean your kitchen.
Subscribe to my newsletter
Read articles from Carl Eubanks directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
