Published on 05 January 2026 under the Coding category.

In my last blog post, I noted:

With regard to sustainability [of Artemis], there are several considerations: infrastructure and its associated costs, the time required to maintain the software, responding to user requests and inquiries, and more.

This had me thinking about how to communicate what “the time required to maintain the software” means in more depth. I thought I could add some colour to what maintenance means in the context of Artemis, the calm web reader I maintain, by way of a few examples. I think of maintenance as work that doesn’t explicitly involve adding new functionality, rather keeping existing features going.

Below are some examples of software maintenance in the context of Artemis.

• The Artemis account deletion feature is not working. This is because the process takes longer than it did when I built the feature. It is likely I will need to create a few database indexes. This feature is essential to have, so it’s at the top of my priority list in terms of software maintenance. Of note, this is an example of maintaining code that worked at one scale but not at another.
• Separately, as I have introduced new features over time, I have updated the account deletion feature so that all database tables are cleared on account deletion.
• Occasionally users are logged out on mobile devices. This is a hard-to-debug problem because it happens irregularly, and only in specific contexts. The first thing I need to do is gather more information, but as I have only received one report of this being a problem it is presently low on my list of priorities.
• A user’s feed lists all posts published on a given day under a heading in the form “Monday, January 1st”. When New Years Day came, I realised the dates in the list of posts in a user’s feed may go from January 1st at the top to December 31st as the next entry, without stating the years to which the dates correspond. I plan to add the year to the dates in the user’s feed headings when the year changes.
• All account settings used to be on one page, but I reorganised them into several separate pages connected by a universal navigation so that it was easier to find each one.
• Sometimes a web feed can’t be processed as expected. This is something I debug on a case-by-case basis – the reasons for a feed not being processed can vary widely.
• At one point, when I introduced a new feature, I was informed that logging in with one’s domain name stopped working. I fixed the issue, then realised it could have been avoided by creating a better abstraction in a certain part of the project codebase where the same code is – inefficiently so – repeated almost but not quite exactly.

Maintenance comes in many forms – whether fixing things that no longer work properly with time (as is the case with the account deletion feature), identifying edge cases (as is the case with showing years alongside dates in a user’s feed at the beginning of a new year), keeping features in sync, and more.

In addition, maintenance tasks can demand varying amounts of time – a bug may be easily fixed on account of being relatively obvious to identify and address, or take a substantial portion of time to first debug, then plan a fix for, then finally make the requisite fix.

The urgency of maintenance tasks varies, too – some tasks need to be completed at the earliest convenience, others can wait until time allows.

Software doesn’t exist in the background, running on for ever and ever. Indeed, there have been weeks when Artemis has run quietly in the background without any effort required from me. But there are other weeks where I get a bug report or notice something isn’t quite working as expected or see a small way in which something can be improved which prompt me to plan, code, test, and release a change. This is what maintenance means to me in the context of Artemis.

Some maintenance tasks can be tedious, some stressful, whereas many others are learning opportunities – a time to learn of a new edge case to consider when coding, for example, or of connecting the dots between multiple parts of a project to build a better mental image of how things fit together.

All in all, there is something amazing about being able to use something you make. But, just as a painting hung in a gallery is in its condition because of all of the work done by staff to preserve it, so too is any given piece of software in its condition because of the work done to maintain it.

Reference this post

Please reference this post with a link to this page. I prefer to be called James (he/him) or James’ Coffee Blog. Learn more

URL for this post: