from Hacker News

Ease of maintenance is a feature

by ronakjain90 on 11/8/24, 2:37 PM with 35 comments

  • by cglan on 11/8/24, 3:31 PM

    Super true. One of the best tests of this is setting up a new laptop. Some of the best experiences are when you get a new laptop, and just clone the codebase and everything works as it did before, no special magic. Golang with vendored dependencies seems to be wonderful for this but I've had relatively decent experiences with newer java projects.

    My worst experiences universally have always been python projects. I don't think I've had a single time where I cloned a python project and had it just work.

    Beyond just the code, I've had lots of mixed experiences with CI/CD being smooth. I unfortunately don't think I've been in a single shop where deployments or ci have been a good experience. They often feel very fragile and undocumented and hard for newcomers.

  • by uludag on 11/8/24, 4:27 PM

    I was reflecting on this article, thinking about what software tools and languages I use that reflect this property, and a weird realization came to mind: Emacs lisp is by far the best language I use in this regard. I literally copy-pasted 20+ year code, eval it, and every time it just works. Then if I want to debug it: C-u C-M-x, and I'm instantly stepping through the code.

    Something this old shouldn't have this property. Nothing "modern" even comes close. Look at the top languages, Python, JavaScript, and Java, and you don't even have to consider too much how abysmal these languages are in this regards.

  • by sethammons on 11/8/24, 3:53 PM

    As a principal software engineer, my life is moving larger orgs closer to this model. I have lived it when it works. It is critical to so many things. I feel like Plato's Cave when I couple this stuff with structured logs, metrics, dashboards, and alerts. So many shops don't understand that this stuff gives you wings.

  • by aaronblohowiak on 11/8/24, 3:34 PM

    I like this. Couple things to add:

    Fast setup and revision are important but incomplete list of maintenance tasks; are metrics/logs predictably named and accessed? Can you perform manual experimentation without hard-to-configure client (ir: hit the server with a browser or run a cli)?

    Also, "cycle time" or "revision time" are soo important, but I havent found a good way to do that with AI model development :( any tips here?

  • by anonyfox on 11/8/24, 8:51 PM

    Nowadays i come to my conclusion that "ease of maintenance" is the most important feature to have in a project. More critical is only that the project in itself is valuable enough, so many engineers optimize things that shouldn't exist in the first place.

    Easy to maintain is not only about keeping something alive with minimal effort over longer periods of time. It also plays a pivotal role for scalability in any direction. Adding more engineers/teams, adding more unforseeable features, iterating quickly in general, surviving more traffic/load, removing technical bottlenecks, ... everything is so much easier when the project is easy to work with and maintainable.

  • by chanux on 11/8/24, 4:18 PM

    Cannot be overstated! I've spent countless hours trying to understand systems built by others (dozens of others of various skill levels) to try and bring the code to a more maintainable posture. Sometimes it feels like a thankless job but it's a rather selfish endeavor because first and foremost, I want to save my future self from suffering.

  • by stevepike on 11/8/24, 4:39 PM

    I think the kind of application here matters a lot, specifically whether you're trying to make a change to a web app or if you're hacking on library code.

    In ruby, for example, I can pretty trivially clone any open source gem and run the specs in < 5 minutes. Patching something and opening a PR in under an hour is definitely standard.

    On the other hand, getting a development environment running for a company's proprietary web app is often a hassle. Mostly though this isn't because of the language or dependencies, it's because of:

      - Getting all the dependent services up and running (postgres version X, redis Y, whatever else) with appropriate seed data. 
  - Getting access to development secrets
    My company (infield.ai) upgrades legacy apps, so we deal with setting up a lot of these. We run them in individual siloed remote developer environments using devcontainers. It works OK once we've configured the service containers.

  • by afiodorov on 11/8/24, 4:02 PM

    More software is written than kept. It's harder to write useful software than to configure CI/CD. The latter is a problem that has been solved before, whilst chances of any software codebase being useful enough that it is even worth maintaining are very low.

  • by godshatter on 11/8/24, 3:59 PM

    Based on the subject I thought this would go in a different direction: document well, take the simple approach where possible instead of the most clever one, modularize well, etc.

  • by megamix on 11/8/24, 3:51 PM

    This is so important. It's the most practical and future-proof way forward.

  • by braza on 11/8/24, 4:31 PM

    For the folks that wants a structured reference around maintenance, this book [1] it's one of the best of the topic.

    [1] - The Innovation Delusion: How Our Obsession with the New Has Disrupted the Work That Matters Most - https://a.co/d/eInjwZD