Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ease of maintenance is a feature

ronakgothi.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Ease of maintenance is a feature

#31

Post by bobertlo »

godshatter wrote: post #11

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.

I think the author did a good job of challenging my assumptions going in at least, which is nice.

My initial reaction was that it was a list of fairly complex things, but they are not necessarily complex to implement, even if people commonly over-complicate a couple of those things or make them a pain for other developers to setup, which seems to be part of the point.

Re: Ease of maintenance is a feature

#32

Post by karthink »

uludag wrote: post #23

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 pro…

> Something this old shouldn't have this property.

It's not an accident -- reading through the emacs-devel mailing list, it's easy to see how much effort the maintainers pour into backward compatibility. It's one of Emacs' unspoken guiding principles[1].

At the same time, it's not that surprising either. Emacs does not have other objectives that more modern languages/ecosystems do: no revenue or growth targets, corporations or VCs breathing down its neck, or a mandate to be "modern". Its most vocal and experienced users, who are also its volunteer maintainers, decide what its priorities should be. Since they've been using it for decades, backward compatibility is high on the list.

[1]: It's "spoken" guiding principles being to further the goals of the GNU project.

Re: Ease of maintenance is a feature

#33

Post by adammarples »

AlienRobot wrote: post #22
cglan wrote: post #2

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 do…

I love Python but it always amazes me how hard it is for it to just... work. So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it. Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv ju…

My recent workflow is to use a great program called mise. You have a config file in your directory and hey presto, python venvs work, they install themselves if they don't already exist, and it will install the exact version of python you specify in your config. On top of that is will set environment variables for you and unload them when you change directory. If you combine this with uv (just tell mise you want uv installed in the config) you can run uv pip sync and instantly reflect any changes in your requirements file directly into your venv very quickly.

Re: Ease of maintenance is a feature

#34

Post by adamc »

aaronblohowiak wrote: post #28
imp0cat wrote: post #20

Earlier quoted context omitted.

I quite like docker for local development. Docker and docker compose do make it incredibly easy to start everything that's required for local development and testing. Your service A needs B and C? Grab those images of B and C and run them all on your machine. The only limitation is the amount of RAM you have available locally. And if you think a bit about your Dockerfiles (ie. have the layers set-up to take advantage…

Yea all of that is stuff I do not want to bother with. At all. “It’s nice if you take on maintenance burden of a bunch of additional moving parts” is the opposite of what I want. If you have to support a diverse set of languages / runtimes / environments and you deploy using containers, maybe it makes sense, but that seems like a use of the complexity budget I’d rather spend on… something else

In big organizations, it solves a lot of problems. Docker isn't perfect (hence interest and growth of Nix), but in day-to-day use it's fairly replicable.

Re: Ease of maintenance is a feature

#35

Post by tmnvix »

AlienRobot wrote: post #22
cglan wrote: post #2

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 do…

I love Python but it always amazes me how hard it is for it to just... work. So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it. Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv ju…

For the past 4-5 years this is what has worked exceptionally well for me:

- pyenv for installing multiple versions of python on my machine

- direnv for managing environments (env variables, python version, and virtual environment)

- pip for installing dependencies (pinning versions and only referencing primary packages in requirements.txt - none of their dependencies)

This makes everything extremely easy to work with. When I cd into a project directory direnv loads everything necessary for that environment.

Each project directory has a .env and a .envrc file. The .envrc looks something like this:

    layout python ~/.pyenv/versions/3.11.0/bin/python3
    dotenv .env
Absolutely no headaches working on dozens of local python projects.

Re: Ease of maintenance is a feature

#36

Post by porridgeraisin »

pphysch wrote: post #19
cglan wrote: post #2

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 do…

> 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. I got a new Chromebook from work, and had VSCode+Docker running an existing Postgres+Django+etc dev environment in literally 15 minutes. I was shocked. Devcontainers are magic, and poor Python DX is a skill issue.

> Poor Python DX is a skill issue

Oh yes, the language whose ecosystem only hears about backwards compatibility in their own death marches? Not their problem. It's the developers, it's _their_ problem.

Not the standard library which _removes_ packages, breaking code which I recently cloned. See "imp".

And not the next python version, which throws a syntax error on bare excepts, breaking old code for absolutely zero benefit beyond pretending to be a linter.

Re: Ease of maintenance is a feature

#37

Post by fragmede »

AlienRobot wrote: post #22
cglan wrote: post #2

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 do…

I love Python but it always amazes me how hard it is for it to just... work. So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it. Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv ju…

yeah I wrote python-wool and set it as my local alias for python so it does just look for a venv in the called program's path, and use that.

https://github.com/fragmede/python-wool

Re: Ease of maintenance is a feature

#38

Post by anonyfox »

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.

Re: Ease of maintenance is a feature

#39

Post by KronisLV »

tmnvix wrote: post #35
AlienRobot wrote: post #22

Earlier quoted context omitted.

I love Python but it always amazes me how hard it is for it to just... work. So there is virtualenv, built in, but... if there is a venv directory, Python doesn't just use it. Like you have app.py, and you python app.py, that doesn't run it with the venv python. This leads to all sorts of problems with scripts that assume they're running under venv. Which means you probably want to write a script that sources venv ju…

For the past 4-5 years this is what has worked exceptionally well for me: - pyenv for installing multiple versions of python on my machine - direnv for managing environments (env variables, python version, and virtual environment) - pip for installing dependencies (pinning versions and only referencing primary packages in requirements.txt - none of their dependencies) This makes everything extremely easy to work with…

> Absolutely no headaches working on dozens of local python projects.

The other day, I moved over to a new container base image that's supposed to run Ansible inside of it. Almost immediately, when trying to manage a RHEL8 compatible host, I got this error: https://github.com/ansible/ansible/issues/82068

I've had issues not only with Python projects that I write, but also with software that's relying on it. Then again, while there are both problems and ways around those, my experience has been similar with pretty much every tech stack out there: from Java apps that refuse to run on anything newer than JDK 8 (good luck updating dozens of Spring dependencies across approx. half a million lines of code in a codebase that's like a decade old), to hopelessly outdated PHP versions or software that works on ancient Yarn versions but not on newer ones and doesn't even build correctly when you move over to Node with npm or software that's stuck on old Gulp versions. Same for Ruby and Rails versions that will run, or .NET and ASP.NET codebases, where the framework code ends up being tightly coupled to the business logic, don't even get me started on front ends that rely on Angular (or AngularJS), Vue (2 to 3 migrations) or React. I've had Debian updates break GRUB, AMD video drivers for the iGPU on the 200GE preventing it from booting, differences between Oracle JDK and OpenJDK having a 10x impact on performance, Nextcloud updates corrupting the install, the same happening with GitLab installs, just a day ago I had a PostgreSQL instance refuse to start up with: PANIC: could not locate a valid checkpoint record. PostgreSQL, of all software.

Sometimes churn feels unavoidable if you don't want code to rot and basically everything is brittle. All software kind of sucks, sometimes certain qualities just suck a bit more than the average. Containers and various version management tools make it suck a bit less, though!

Post reply on HN