Code bases should not grow forever
Today we discuss how to avoid code maintenance hell
As software developers, we are taught to believe that we should always be writing code and adding more to our current code base.
This is a half-truth. Although not intentional, has caused a lot of issues that teams deal with on a daily basis. Every line of code comes with a price, and all your code over time adds up to make your maintenance cost. The more code you write, the more code you have to maintain.
The reason it’s this way is simple, there are more new developers starting every day than existing developers needing guidance on maintenance practices. The market rewards those who cater to the largest groups. Meaning, that teaching how to write code is more profitable (and intriguing) than teaching how to maintain code that’s already been written.
The idea of always adding code gave birth to a bunch of problems in our community. It has left vital information hidden from young developers (not in age, but in experience) leaving a notable gap between those that know it and those that don’t. Things like:
Importance of writing testable code
Setting up remote logs to monitor code base health
Analyzing user behavior to understand underutilized code
Setting up crash reporting to understand a user’s experience
Allocating time to either reduce code complexity or remove it completely
Constantly growing a code base takes you straight to maintenance hell
Maintenance hell is where the time it takes to maintain the code is greater than the time it takes for you to add new work.
Let’s say you spend 1 week (5 weekdays) building a feature in your app, then it takes another week to do the QA → bug fix → QA process before you release. This means you’re very close to maintenance hell. Eventually, it means that when you make a change, you’ll have to allocate more time to do code maintenance than build the feature.
If you extrapolate maybe just a few feature releases down the line you will eventually be spending the majority of your time on maintaining your code, instead of building new features. Imagine how management will feel if a 3-day task takes 2 weeks due to maintenance procedures.
Make it a priority to remove/reduce old code, or deliver self-testing code
If we shift our mindset to understand that we should equally value, removing code, reducing complexity, or adding automated testing, our code bases can continue to grow, but in a healthier way.
Instead of each feature increasing maintenance cost, if we add a requirement for automated testing, each feature can actually decrease overall maintenance cost. This means over time it’ll take you less time to test your code, which sounds ridiculous, but it’s possible.
On the opposite side of code maintenance hell, imagine you spend 3 days building a feature and you can fully test it in 30 minutes. Or the feature that’s always taking the longest to test is removed, or reduced based, cutting your time to test that code in half.
These are all possible if we value removing code, reducing complexity, or adding testing as much as we value writing net-new code.
We don’t write software to be used for 3 weeks, it’s long-term, eventually, we’ll start to educate even beginners with this mindset.
At the moment developers are taught to believe that writing code is all they need to do and once their code is done, their “job is complete”.
All of us reading this know that’s not the case, and it’s our job to put this idea into practice and educate the newer developers in our team, or the stubborn old ones who still believe they write the perfect code every time ;)
The shift we have to make is small, but the results are outstanding. As developers we want to write code, and if all we do is maintain old code, burnout becomes much more of a reality even if the work environment is amazing.
Thanks for reading. See you next week.
Dane
Let’s work together
Book a 1-on-1 call with me to take the next steps for your Flutter project.