[shantly]

> How would you write your code today if you knew it would of been your last commit and still in use in 30 years ?

Generally: minimize dependencies. External library or API dependencies? Versions can drift, the system can change out from under you in incompatible ways. That goes for the OS, too, of course. Data dependency that you aren't 100% in control of? Same. All are forms of state, really. Code of the form "take thing, do thing, return thing, halt" (functional, if you like—describes an awful lot of your standard unixy command line tools) is practically eternal if statically compiled, as long as you can execute the binary. Longer, if the code and compiler are available.

[throwaway55554]

> Generally: minimize dependencies.

This. It doesn't mean go overboard with NIH, but you have to evaluate and select your dependencies judiciously. It's not about developer productivity with these types of products.

Also, make as much of your program configurable as possible so you can tweak things out in the field. For example, if you have a correlation timeout. Make that configurable. But don't go overboard with that either. :)

[lostcolony]

Another aspect of this is pick dependencies that are well encapsulated (so if you need to change them or update them it's generally easy to).

Of course, this is just a good choice regardless. Still, it shocks me how often people will choose libraries and frameworks that require very opinionated structure on large swathes of code, rather than having well defined minimal touchpoints.

[cpeterso]

And vendor your dependencies, archiving tested and blessed snapshots in your version control instead of pulling them live from GitHub, NPM, or BinTray.