• 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:

    How did we decide to have a kid?

    ...and then some more kids? The post How did we decide to have a kid? appeared first on Otherwise.

    via Otherwise January 28, 2023

    My Rainbow Kit

    For Christmas I got a really fun kit about rainbows. It had a rainbow catcher, a really cool necklace, a streamer thingy, and it also had a really really cool pinwheel, and it also had a bracelet and a pinata. Unfortunately the pinata didn't work out …

    via Anna Wise's Blog Posts January 5, 2023

    Phones

    I think that once a kid is in third grade they should be able to get a phone. I think that while sometimes parents might want kids not to have them at certain ages, phones can be quite useful at times. Tablets don't have GPS, they don't have WiFi…

    via Lily Wise's Blog Posts January 5, 2023

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact