• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • Designing Low Upkeep Software

    September 25th, 2021
    meta, tech
    It's common for me to get excited about a personal project, put a bunch of time into it, and then lose interest. As much as possible, I want these projects to continue working; upkeep isn't fun. What does designing for minimum maintenance look like?

    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 do-release-upgrade 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

    Recent posts on blogs I like:

    Moral aesthetics

    “Doing good” differs by subculture The post Moral aesthetics appeared first on Otherwise.

    via Otherwise September 29, 2022

    Futurist prediction methods and accuracy

    I've been reading a lot of predictions from people who are looking to understand what problems humanity will face 10-50 years out (and sometimes longer) in order to work in areas that will be instrumental for the future and wondering how accurate thes…

    via Posts on September 12, 2022

    On the Beach

    I really like going in the water and this beach is a great place for building sand castles and boogie boarding. I also like trying to float on top of big waves. I'm not very good at it. I only float on the flat waves.

    via Anna Wise's Blog Posts July 12, 2022

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact