Over my relatively short career (6+ years), I’ve noticed a change in the way I approach building things. When I was still an inexperienced junior developer who barely survived operating in a Linux environment and saw backend development as a black box, I was happy to get things working at all.

Nowadays, no matter what I do, I have to take maintenance into account.

image

In software development, having to account for maintenance means being picky about what dependencies to include.

Do the developers of the dependency have a good track record?

Does it still receive regular new releases?

How often does it break compatibility with new major releases?

Would it be possible to avoid including the dependency by going with another solution, such as writing a small amount of code yourself?

Is this project maintained by a single person?

Or solely by a VC-backed company that is burning through cash fast?

What if that company has layoffs or goes under?

If you ask yourself these questions, you’re probably going to make a choice that’s at least somewhat informed, and you might be able to avoid some pain later on.

It’s a gamble

But sometimes you just can’t win.

When working as a junior developer, I was happy to add yet another dependency to the project because it solved that one particular problem I was working on without me having to worry about implementing the functionality myself. I really didn’t give much thought to what would happen to that dependency years from now.

After working in multiple software development teams, I know how painful it is to get a neglected software development project back on track (hi, T3!). Choices made in the past (and not necessarily by you) can interrupt your team and put brakes on any other development that you were planning on.

One relatively recent example comes to mind. I wasn’t working on this change myself, but saw how it affected the team. There was a frontend project based on React, Redux and a bunch of other pieces that were thrown together. One of those dependencies was a library that was used to render all sorts of tables. There was just one little issue with it: that dependency was now unmaintained and blocking updates to other dependencies in the project, like React. One abandoned library that was utilized in a good chunk of the project meant that another solution had to be chosen and all existing usages had to be ripped out. Given the poor technical state of the project in general (and that’s putting it nicely), that was no easy task, and many weeks were spent on trying to get the house in order. Eventually the team succeeded, but the cost was high, all because a choice made in the past did not pay off.

You might do some basic research, consider the ups and downs of all the choices, and still make a choice that will haunt you or the next developer. Sometimes it’s simply a coin toss. Life happens, and developers are not immune to it. The developer might be working on that one library as a passion project, but decide to quit after burning out. Or they get other priorities, like starting a family, or they decide to switch careers entirely. Or they might have simply passed away. Such is life.

The issue with tutorials

If you’re looking to solve a particular problem, you’re probably going to go straight to your search engine of choice and throwing in some related keywords.

Looking at what’s out there in terms of tech often results in browsing through search results and a bunch of tutorials. Those tutorials are often focused on the bare minimum: here’s what we’re setting up, here are some commands that you need to run to get there, and et voilà, you have something that works!

When was the last time you saw a tutorial that also focused on the maintenance of that solution?

If you’re new to this industry, maintenance is not something that you necessarily think about as you’re most likely focused on getting things to work in the first place. Building things, exposing them to the world and then ignoring maintenance is one of the many reasons why the software landscape is in shambles. Best case scenario, the world around your little service updates and introduces outages that you could have avoided with a little love and care. Worst case scenario, you get in the crosshairs of a bot that’s scanning the whole Internet for vulnerable services, and your little service might be following orders from adversarial countries and taking part in cyberattacks.

If you’re setting something up, think about what the maintenance will look like, and try to estimate the amount of time you’ll have to spend on it. If you can automate a big part of maintenance, then that’s even better.

You should still build new things, but you can’t ignore maintenance.

If you’re someone who just realized that they have this one web service running on a VM somewhere in the cloud with uptime measured in years and no automatic updates being applied, then I guess you now know what you’ll be working on this week.

Not Just Software

Maintenance applies elsewhere as well.

You decide to buy a smartphone, and you care about using the hardware for a long time, perhaps 5+ years. Perhaps due to environmental concerns, or due to smartphones being ridiculously expensive in 2023.

This means that you probably want one where you can replace the battery with a reasonable cost, since that’s considered to be a consumable item in electronics and it will eventually stop holding a charge.

Which option would you go with?

  • Apple iPhone 14, battery replacement takes 1-2 hours and specialized tools
  • Google Pixel 7, again, 1-2 hours and specialized tools needed
  • Fairphone 4, 30-60 seconds to replace the battery, no tools needed if you can pry the back cover up with your fingernail

From this perspective the Fairphone 4 is the obvious choice. You will have to consider other aspects as well when picking a smartphone, such as the camera quality, performance and any other features you expect from it, so it’s not always about maintenance, but it can still play a big part in the decision-making process.

Or let’s consider a laptop instead. You can cheap out and get one with the lowest price from the store, but it’s unlikely to last more than a few years before it has issues, and repairing it might not make sense due to lack of spare parts or the repairability of the device being a nightmare. If you care about longevity, you can instead opt for an used business-class laptop that has better physical construction and lots of affordable spare parts available for quite a long time.

If you can forego having a car, then that’s a load off your back, since those hunks of metal tend to attract all sorts of problems and require expensive maintenance. Trust me, I have one made by a certain German car manufacturer notorious for having expensive repairs, and it’s not fun.

When choosing a place to live, consider that a bigger apartment or house will have a larger surface area for problems to exist. More rooms, more area, more things that need attention and repairs.

If you start looking at the choices you make through the lens of maintenance, you can reduce the amount of time and money that you’ll later regret having to spend due to choices made in the past. Any new object you acquire will likely need maintenance for it to last for a long time. Are you willing to put in that effort? You’ll be paying either way, with your money or your own time, or both.

Free tech tip to developers

If you’re having trouble explaining the need to perform regular maintenance in your software development project to the business side, then try using an analogy. Most people probably would not want to work in an office with broken windows, a leaky roof and the heating system malfunctioning, so why should your software get treated differently?

Conclusion

Maintenance is something you can’t ignore. It will catch up with you eventually, and it will not let you choose the place or time for it. If you make conscious decisions, you can reduce the burden and avoid some of the pain later on.