This seems like another case where jblow's opinions are guided by his experience as a game dev. Games can be "finished" and never touched again. I think I mostly agree with him that software could be made to be timeless to some degree. But, in the world of web apps and saas, the culture is to offload much of the work to third party libraries/APIs which locks you into a never-ending cycle of dependency management. I don't know if this culture is totally necessary (maybe to ship fast and keep up with security updates?), but in a world where users expect software to be constantly improving you can't expect anything to be "done". Maybe you could get close if you built everything in-house, but even still you have to keep up with security flaws.
kevmo314 · 12h ago
> The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies.
A lot of value is driven from those dependencies though. Zapier as a pointed example: Zapier sans dependencies is ... well I don't even know. So sure, you could avoid dependencies at all cost, but at some point you might end up deleting the reason someone else wants to use your code in the first place.
Of course, if you're writing code only for yourself that will totally work, but most professional software engineers are not -- it's a balance and it's not fair to say all they have to do is stop writing glue code.
caseyohara · 11h ago
I've been working on the same product for ~13 years and I can confidently say the most important thing to ensure the longevity and long-term maintainability of a codebase is aggressive minimization of dependencies.
Engineering is all about compromises. If near-term velocity is more important to you than long-term evolution and maintainability, then go ahead and use all of the dependencies if it allows you to ship faster. But that is a form of technical debt that you will have to pay down eventually.
j45 · 11h ago
Your example of Zapier dependence resonates - being sure to put a simple layer between your code and Zapier is the critical component.
The code makes the same call to a Zapier type command but it could be routed to Zapier today, and somewhere else in the future.
This can take a nominal amount of time longer than integrating Zapier directly.
It could be a couple more tables to setup and manage, or it can be done in the code somewhere.
burnt-resistor · 9h ago
Well, when I was in school, the goals were wide compatibility and portability. I was writing network C code in the 00's that could run without any changes on Windows, Linux, FreeBSD, HP-UX, AIX, SGI, SCO, and Solaris.
Code only "rots" when its dependencies rot from assholes who churn the language or break API promises. These low expectations lead to normalization of deviancy that churn without clear and present value is "okay", when it's merely job security or coding theater to appease others that everything must be touched and changed constantly or otherwise it's "broken".
juancn · 11h ago
I kind of agree. There's another world, where software lasts a really long time, it's a much better world, but just a few of us get to live in it.
Building tools for other engineers is where it's at, the library maintainers for long lived libraries, like libc or any collections library.
If you get a sorting algorithm in a mainstream language library, it will likely live forever (or forever-ish in software terms).
The harder the problem you solve (in the math sense) the more likely that if you craft that code properly and carefully, it will outlive you.
boznz · 11h ago
Software in a closed ecosystem should run for the life of that ecosystem, an example would be Firmware on a non-connected device. eg the ECU in my car from 1991.
henning · 12h ago
I was about to comment how easy Zig makes it to make platform layers where the right code for an OS is compiled at compile-time and AFAIK there is no runtime cost, it's basically conditional compilation. But the Zig language itself is incredibly unstable and code you write now probably won't compile a year from now.
See uxn and justification: https://wiki.xxiivv.com/site/now_lie_in_it.html
And https://100r.co/site/story.html
A lot of value is driven from those dependencies though. Zapier as a pointed example: Zapier sans dependencies is ... well I don't even know. So sure, you could avoid dependencies at all cost, but at some point you might end up deleting the reason someone else wants to use your code in the first place.
Of course, if you're writing code only for yourself that will totally work, but most professional software engineers are not -- it's a balance and it's not fair to say all they have to do is stop writing glue code.
Engineering is all about compromises. If near-term velocity is more important to you than long-term evolution and maintainability, then go ahead and use all of the dependencies if it allows you to ship faster. But that is a form of technical debt that you will have to pay down eventually.
The code makes the same call to a Zapier type command but it could be routed to Zapier today, and somewhere else in the future.
This can take a nominal amount of time longer than integrating Zapier directly.
It could be a couple more tables to setup and manage, or it can be done in the code somewhere.
Code only "rots" when its dependencies rot from assholes who churn the language or break API promises. These low expectations lead to normalization of deviancy that churn without clear and present value is "okay", when it's merely job security or coding theater to appease others that everything must be touched and changed constantly or otherwise it's "broken".
Building tools for other engineers is where it's at, the library maintainers for long lived libraries, like libc or any collections library.
If you get a sorting algorithm in a mainstream language library, it will likely live forever (or forever-ish in software terms).
The harder the problem you solve (in the math sense) the more likely that if you craft that code properly and carefully, it will outlive you.