Maintenance is a creative act

I’ve started going to the gym 7 times (I wrote about it a while ago). Starting was never the problem. The enthusiasm lasted about a week every time, and everything after that week was the hard part.

Projects are the same. A launch is easy to recognize because it has a date, a screenshot, maybe a small celebration. Keeping the thing useful for five years has none of those moments, even though it usually takes more thinking. I think the way we talk about creativity undervalues this second kind of work.

Repair almost never means returning something to its original state. The original part isn’t available anymore, the users need something different, a dependency has changed. To keep the thing useful, somebody has to come up with a new arrangement, and that’s design work.

It helps to ask what was valuable in the first place. Was it this particular code, or what people could do thanks to it? Sometimes staying faithful to the original matters a lot. Other times taking care of something means changing it.

That’s why I think documentation is part of the product. In open hardware, the information needed to understand and modify a design is part of what makes the design open (more on that in Access is more than a download), and I’d apply the same to software. A system nobody explained can outlive its author’s attention and get harder to care for every month.

AI systems make this harder. Their behavior depends on model versions, tools, connected services and how people use them, so one successful demo says little about next year. NIST’s AI Risk Management Framework from 2023 is organized around governing, mapping, measuring and managing risk as ongoing work, and what I take from it is that evaluation continues for as long as the system lives.

A situation I can easily picture: a small company sets up an automated assistant that saves several hours a week. The person who configured it leaves. Six months later a connected service changes, things start failing, and nobody knows if it’s occasional or systematic. Nobody has the authority to switch it off either, because other work depends on it.

What was missing there is an arrangement for care: who notices problems, who is allowed to change the system, who has time for it, and when it’s ok to retire it.

Not every prototype has to become an institution. Temporary things are fine, as long as they’re allowed to end clearly. An abandoned experiment that became somebody’s critical dependency without anyone deciding so is something else.

So for my own projects, I’d like “done” to include an answer to who takes care of it next. It can be me, a paid maintainer, a community, or a documented way to shut it down.