Don’t Wait Until It Hurts: Software Maintenance Matters


Last week, I went to the dentist to find out that I needed to fix a hole in a tooth.

This week, I went to the dentist to fix it.

When you think about it, you see similarities between caring about your smile and maintaining software.

There are mainly two different approaches.

You either wait until your teeth hurt so much that you cannot eat anymore or regularly visit the dentist for a check-up.

It’s the same for maintaining software.

You can continue implementing new features and fixing bugs without caring about the architecture or the product’s longevity for years.

Or you can keep it up to date, modernize it, and fix architectural issues along the way - one step at a time.

I have been part of large software rewrites where the old software was 20+ years old.

As a young software developer, I thought it was natural that software was in a bad state after developing it for a long time.

Now that I grew up as a software engineer, I realized that age isn’t the deciding factor.

I have seen messy products within their first 2 or 3 years of existence. I also saw products that have been in production for over a decade and are still maintainable, extensible, and performant.

So what’s the deal?

Keeping software up-to-date, maintainable, and modern is an ongoing task.

It’s not something that gets done automatically or that you can skip for 20 years and do “when you have the time” or “when you have the budget”.

We need to find ways to constantly modernize the code, keep it maintainable, and fix old burdens.

Take the .NET platform as an example.

Yes, you could keep your software from 2020 on .NET 5. There were many changes in the platform within the last 4 major releases. At some point, the migration to the current version will be painful and expensive.

Or you go from version to version with minimal effort to keep it current.

I know that management and other team members sometimes want to decide what you work on. It’s usually not a problem.

However, when it comes to keeping software maintainable, we need to be active and take responsibility.

Slide in an hour or two to remove an unsupported method from the source code when fixing a bug. It helps to make the migration to the next version simpler.

Always look out for changes in the next version of your platform or framework and ask yourself what you can do today to make the migration simpler in the future.

Again, keeping software maintainable is an ongoing process, and we, as professionals, need to find a way to spend the time to improve it.