Designing Low Upkeep Software
|September 25th, 2021|
The biggest piece is minimizing your dependencies, and limiting them to ones that value backwards compatibility. Most of my projects are on the web, which means I have an unavoidable dependency on browsers, but this is fine because browsers strongly prioritize keeping existing websites working.
On the server I run Ubuntu LTS until it's near the end of its
supported lifetime. Every two years I run
and move to the next one. This cost is shared over many
jefftk.com projects, so it isn't too bad.
Many projects can just be hand-written HTML/JS/CSS. No build system, no libraries, just speaking the browser's native languages. These don't need any technical maintenance; they just keep working.
One step from there are projects where I need a little bit of server-side support. For example, I write my blog posts as plain HTML, but I need headers, footers, indexes, and RSS. Each time I change my site I run a script which creates/updates all these additional files. If I want to change something about the presentation of my site then I need to dig into code, and very occasionally something will break when updating the site, but just displaying my existing stuff doesn't require any maintenance.
Then we get to the tricky stuff: projects which need real time custom code. Things like Bucket Brigade and blog comment inclusion. How I approach this:
Code in python, with no dependencies beyond the standard library. As with browsers, python rarely drops support for widely used functionality. Moving to python3 was a bit annoying, but I waited a long time and then used 2to3. Avoiding dependencies made this easy.
Store data on the file system, including for caching. It's not as elegant as a proper database, but it doesn't require an additional process or dependency. Debugging and backup are very simple, because everything is visible.
Implement as much as possible on the client.
Leave out features if they can't be implemented simply, or would require more than minimal server-side processing.
For example, I taught my comment requester to fetch comments from the EA Forum and LessWrong two years ago, and I don't expect to have to think about that code again until there are breaking changes to the upstream API.
This is not how I approach design at work, or necessarily how I would recommend doing so. Having a budget where initial creation is essentially free (fun!) while maintenance is extremely expensive (drugery!) is a dramatic exaggeration for most software development. But this process works very well for my hobby code.
Comment via: facebook, lesswrong, hacker news