Live data from Hacker News

Ease of maintenance is a feature

ronakgothi.com

11–20 of 39 posts

Re: Ease of maintenance is a feature

#12
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.

Re: Ease of maintenance is a feature

#13
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'm curios if you can spot a pattern in the platform (win/osx/linux), type of project, or is it all over the place?

My own experience with Python boils down to creating a virtualenv, installing the deps, setting up configuration (or just copying it from somewhere) and creating a database, and I'm off to the races. The only exception in recent memory was when a project had two dozen microservices, half of the codebase was on private package repository, and we used Poetry. The combo required somewhat more involved setup. That said, IIRC all the projects had fully pinned package versions (package==x.y.z).

In contrast, every time I touch something in JS land I get the same experience you described for Python. On one project we literally copied node_modules across machines (including servers), because it was unbounded amount of time trying to do a full reinstall. Anecdotally, amount of churn in JS is much higher, and the maintenance load increases proportionally.

Usually it's something like:

- have a project in JS with some dependency X that's no longer on the bleeding edge, but works nice

- want to depend on a new package Y for some new feature

- the new package Y depends on a library Z that's higher than what the other dependency (X) can work with

- try to update the original dependency (X)

- wailing, gnashing of teeth, and considering the switch to agriculture instead

In my experience, if you're not closely tracking the bleeding edge, upgrading packages and updating your code accordingly, your JS developer experience will be abysmal.

Agree on the CD part, especially the fragility and more manual work than if the deploy is some manually driven (semi-)automated process.

Re: Ease of maintenance is a feature

#14
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…

You may want to consider using Nix, with nix flakes.

How much of that just hides complexity? I remember back in the day hiding a large amount of complexity behind vagrant.

A new dev could get up and running quickly with "install vagrant; vagrant up", but that was hiding a lot of complexity behind a very leaky abstraction.

Re: Ease of maintenance is a feature

#15
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…

[deleted]

Re: Ease of maintenance is a feature

#16
post #13
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'm curios if you can spot a pattern in the platform (win/osx/linux), type of project, or is it all over the place? My own experience with Python boils down to creating a virtualenv, installing the deps, setting up configuration (or just copying it from somewh…

You can get the same JS/node_modules experience with Python, just use pdm. ;)

Re: Ease of maintenance is a feature

#17
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.

Re: Ease of maintenance is a feature

#19
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.

Re: Ease of maintenance is a feature

#20

Earlier quoted context omitted.

I have a couple decades of experience and have ridden a small start up through public and I have worked intimately with 6 companies. I know about taking a product and ultra scaling it in both technical and organizational scale. I will never recommend Python outside of a small team. It is organizational molasses. My current company has multiple teams striving to keep our Python tech stack serving our growing technical…

The hoops that people go through to solve this sometimes creates something even more complex and not great, like forcing all development into a docker container.. Ever try conda though? I’ve had moderate success with pipenv, but tbh I don’t love it as it hides too many things when installing a package fails.

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 of caching, have icecc+ccache mounts for c++ projects to distribute compilation and cache results, have mounts for apt or other package manager cache downloaded packages that you use) the local image rebuilds can be quite fast. Those are the little tricks to make your life with docker less miserable.

Post reply on HN