Maintenance matters, even when you can’t see it

Software maintenance is not very exciting.

There. I said it.

New features are exciting. A new user interface gives you something you can show in a screenshot. A new planning feature gives you something interesting to write about.

Updating an old library to a current version?

Not so much.

But it may be some of the most important work we do.

Getting rid of technical debt

I am currently working full-time on LibrePlan 1.7, and a large part of that work is about something users will hopefully hardly notice: getting rid of years of accumulated technical debt.

LibrePlan has a long history. That is something to be proud of, but it also means that over the years dependencies become outdated, technologies move forward and security tools discover issues that simply weren’t known when those components were originally selected.

So for LibrePlan 1.7, we are doing some serious housekeeping.

And the results are becoming visible.

Our dependency and security scans now report about 90% fewer known vulnerabilities compared with LibrePlan 1.6 releases.

There is still work to do, and not every reported vulnerability represents an exploitable problem in LibrePlan. Especially when using our Docker deployment, many affected components are not exposed through the web application at all.

Nevertheless, the trend is what matters: the underlying software stack is becoming considerably more modern and healthier.

Technical debt is still debt

Software has this annoying property that it doesn’t remain modern simply because nobody changes it.

The world around it changes.

Java changes. Libraries change. Browsers change. Operating systems change. Security knowledge changes. Build tools change.

So even perfectly working software slowly accumulates technical debt.

And just like financial debt, ignoring it doesn’t make it disappear. Eventually, you have to pay it back.

That is exactly what we are doing now.

From Java 11 to Java 25

One of the biggest changes in LibrePlan 1.7 is the move from Java 11 to Java 25.

That sounds like a simple version number change.

It isn’t.

LibrePlan is a fairly large application with a long history, and moving that codebase forward means updating many, many libraries along the way.

Some can simply be replaced with a newer version. Others have changed their APIs. Some are no longer maintained at all. And occasionally updating one component reveals another dependency that has quietly been waiting for attention for years.

It is not glamorous work.

But it is necessary work.

And with every dependency we modernize, LibrePlan becomes a little easier to maintain for the future.

Can you spot the difference?

I can show you two screenshots.

One is LibrePlan 1.6.1.

The other is the LibrePlan 1.7 beta.

Can you see the difference?

Probably not.

And that’s a good thing.

The purpose of LibrePlan 1.7 is not to redesign the application or move buttons around just so everybody can see that something changed.

The goal is to modernize what is underneath while keeping LibrePlan familiar to the people who actually use it.

The same LibrePlan on the outside.

A much more modern LibrePlan underneath.

Full-time maintenance

I am currently working full-time on this maintenance release.

There are certainly more exciting features I could be building instead. And there are plenty of ideas for where LibrePlan should go next.

But before building another floor, sometimes you first need to inspect the foundations.

That means upgrading Java. Updating dependencies. Replacing obsolete components. Fixing incompatibilities exposed by newer libraries. Improving the build process. Reducing security issues. And generally making sure LibrePlan has a healthy technical foundation for the years ahead.

Much of this work is invisible when it is done properly.

And perhaps that is the best measure of success for a maintenance release.

When LibrePlan 1.7 arrives, I hope existing users will install it, open their projects and initially wonder what all the fuss was about.

Underneath, however, a lot has changed.

And LibrePlan will be in much better shape for whatever we decide to build next.

This entry was posted in Uncategorized. Bookmark the permalink.