Making code last a long time | Hacker News Reader

Making code last a long time

twitter.com

28 pointsrobinhouston11 comments

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.

From experience - if you look at the "security flaws" in detail that updates and patches address, an app with good dependency hygiene is rarely vulnerable to them, and doesn't need the purported fixes. So in those cases it's mostly a comforting mirage that your software is improving as you do "security updates" on your libraries and dependencies, except in rare cases.

And, security updates should not break your app! What breaks your app are feature changes, API changes, and the like, which is a breach of backwards compatibility and IMHO kind of lazy and hostile on the part of the library developers. It creates massive unnecessary work for developers, and unnecessary bugs and problems for millions of end users.

Make and maintain the virtual machine that runs your program, which executes custom instructions.

See uxn and justification: https://wiki.xxiivv.com/site/now_lie_in_it.html

And https://100r.co/site/story.html

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".

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

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.

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.

What are you doing with Zapier that you couldn't do with your own code, or carefully curated small set of libraries? For networked services, the REST APIs of popular providers (Stripe, AWS, etc.) are usually kept backwards compatible for a long time.

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.

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.

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.

Reply on news.ycombinator.com