5 ms·

I never understood the need (desire) to update your dependencies as much and often as possible. As long as a project builds and runs without any issues, why put

I never understood the need (desire) to update your dependencies as much and often as possible. As long as a project builds and runs without any issues, why put effort in upgrading libraries and exposing yourself to possible issues.

r_singh 7y ago
I get where you're coming from, however, I think having an update cycle, even if it's something like once in 18 months, is important, especially as a responsibility one has to their project's successors. There's nothing worse than coming to a project riddled with deprecation warnings and when one tries to update, breaking changes in libraries result in a ton of issues. Also, it can (and most likely will at some point) affect your release dates when unexpected issues arise due to deprecated APIs.
- CaptArmchair 7y ago
  > deprecation warnings That's a smell. It means someone only did a partial upgrade of the stack. This isn't limited to libraries, it also includes everything else, like having the latest version of $language installed instead of an earlier - compatible - version. When you work on legacy, your first step would be trying to get it to run on the intended version of the stack before trying to move towards a recent target. > when one tries to update, breaking changes in libraries result in a ton of issues That's par for the course with any technology. Try replacing the spark plugs of an 1980's car model with their 2020 counterparts. A car restorer would look for matching parts of that era. Updating legacy code is much like Theseus' Ship. You change parts of the ship while sailing. So, whatever you do: you make sure the ship doesn't sink en route. If you're working on legacy, the stakeholders - clients, users,... - aren't interested in specific versions of the underlying libraries. They simply want to get to their destination, and they need a seaworthy ship i.e. usable software. Now, a stakeholder may go "Oh! I want shiny feature X!", but then you might need to go through the pain of upgrading the entire ship. As a programmer, it's your job to put that choice succinctly in front of a PO or PM: "Either it's spending a lot of time & money upgrading, or not having shiny feature X." It's NOT your job or responsibility to decide whether or not the upgrade actually needs to be done. The same is true about security or safety. If a client (or your boss) isn't willing to invest in an upgrade path, then there's not much you can't do about that. Except for walking away - jump ship - if you can't bear to see the storm ahead. There's an iron triangle of trade-offs: cheap / good / fast. Pick two, you can never have all three. As a programmer, your goal isn't to write code with the language du jour. It's solving a problem your boss and / or your clients put in front of you.
toyg 7y ago
Security issues are a thing. They are more likely on the server side, but still.
codebje 7y ago
Unless it's a dead project, failing to perform maintenance will add to the cost of change, ultimately quite sharply.
- owl57 7y ago
  Thanks for putting it that succintly. It got me thinking if that cost of change is always a bad thing. A lot of programs tend to fall into one of two ends of the spectrum: 1) Everyone is afraid to change anything. 2) The program is constantly improving, to the point that I never use that word other than sarcastically. Now, threat (1) is older than computers. But threat (2), though not exactly new, is greatly facilitated by the web platform. Now, when there is real competition, do you find yourself preferring constantly changing apps or crufty ones?
cookiengineer 7y ago
> why put effort in upgrading libraries and exposing yourself to possible issues. Isn't this what the combination of a "package manager" with semantic versioning scheme actually should automate? Personally, I think this is where NPM failed and still fails. They should enforce a binary format that ships with header files (and method signatures), and enforce semantic versioning. If any library doesn't play by the semantic rules, don't let it publish. That's the authority and responsibility that NPM failed to include. If everybody plays by the semantic rules ... then libraries can be upgraded automatically without breaking anything. And a huge plus: They can be installed as _shared_ libraries, which is such an old concept that it hurts my fingers having to type its advantages.
- OJFord 7y ago
  How do you enforce it? Cargo (rust) considered it, using the vastly more information it has about whether signatures have changed than NPM, but rejected it because you can still make breaking changes without changing a function signature, so why claim to detect it if only a subset can be.
  - edynoid 7y ago
    You can get pretty far with a statically typed, purely functional language. For example, Elm's package manager enforces semantic versioning: https://elm-lang.org/ https://elm-lang.org/ I don't think you can do that with JavaScript.
    - OJFord 7y ago
      You can always break an API with the values, however much you do with the types. Its effectiveness also varies with how much and well types are used - e.g. whether you return `String` or `Url` to begin with.
bdg 7y ago
Not updating now prevents you from being able to update later. The entire security thing. Not getting "free value" of performance fixes, bug fixes, new features, etc.
macrael 7y ago
The main reason is security. When a security vulnerability is patched in a new version of one of the libraries you use, you should upgrade, and if you haven't upgraded it in two years it is gonna be a pain in the ass. On one of our projects we've got what I think is the best take on this I've seen. Once a week, CI updates all our dependencies and makes fresh PR. That PR then goes through CI and can be merged by an engineer if it looks good.
tracer4201 7y ago
Security and availability. If you’re at a large company, not updating your dependencies could mean an outage, losing customer or other data you don’t want exposed to the world. A simpler way to state it is it could be the death of your company.
scotty79 7y ago
I always update libraries when I'm revisiting a project. This help me to engage with the project because the thing that motivates me most is if something doesn't work. And after updating libraries something usually doesn't.
knightofmars 7y ago
Because it is a major security issue to not keep up with library upgrades and general maintenance. It's in the OWASP top 10 for a reason. The Equifax breach is a perfect example of why ignoring library upgrades is a high risk behavior for any organization. https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...

r_singh 7y ago

I get where you're coming from, however, I think having an update cycle, even if it's something like once in 18 months, is important, especially as a responsibility one has to their project's successors. There's nothing worse than coming to a project riddled with deprecation warnings and when one tries to update, breaking changes in libraries result in a ton of issues. Also, it can (and most likely will at some point) affect your release dates when unexpected issues arise due to deprecated APIs.

CaptArmchair 7y ago
> deprecation warnings That's a smell. It means someone only did a partial upgrade of the stack. This isn't limited to libraries, it also includes everything else, like having the latest version of $language installed instead of an earlier - compatible - version. When you work on legacy, your first step would be trying to get it to run on the intended version of the stack before trying to move towards a recent target. > when one tries to update, breaking changes in libraries result in a ton of issues That's par for the course with any technology. Try replacing the spark plugs of an 1980's car model with their 2020 counterparts. A car restorer would look for matching parts of that era. Updating legacy code is much like Theseus' Ship. You change parts of the ship while sailing. So, whatever you do: you make sure the ship doesn't sink en route. If you're working on legacy, the stakeholders - clients, users,... - aren't interested in specific versions of the underlying libraries. They simply want to get to their destination, and they need a seaworthy ship i.e. usable software. Now, a stakeholder may go "Oh! I want shiny feature X!", but then you might need to go through the pain of upgrading the entire ship. As a programmer, it's your job to put that choice succinctly in front of a PO or PM: "Either it's spending a lot of time & money upgrading, or not having shiny feature X." It's NOT your job or responsibility to decide whether or not the upgrade actually needs to be done. The same is true about security or safety. If a client (or your boss) isn't willing to invest in an upgrade path, then there's not much you can't do about that. Except for walking away - jump ship - if you can't bear to see the storm ahead. There's an iron triangle of trade-offs: cheap / good / fast. Pick two, you can never have all three. As a programmer, your goal isn't to write code with the language du jour. It's solving a problem your boss and / or your clients put in front of you.

toyg 7y ago

Security issues are a thing. They are more likely on the server side, but still.

codebje 7y ago

Unless it's a dead project, failing to perform maintenance will add to the cost of change, ultimately quite sharply.

owl57 7y ago
Thanks for putting it that succintly. It got me thinking if that cost of change is always a bad thing. A lot of programs tend to fall into one of two ends of the spectrum: 1) Everyone is afraid to change anything. 2) The program is constantly improving, to the point that I never use that word other than sarcastically. Now, threat (1) is older than computers. But threat (2), though not exactly new, is greatly facilitated by the web platform. Now, when there is real competition, do you find yourself preferring constantly changing apps or crufty ones?

cookiengineer 7y ago

> why put effort in upgrading libraries and exposing yourself to possible issues. Isn't this what the combination of a "package manager" with semantic versioning scheme actually should automate? Personally, I think this is where NPM failed and still fails. They should enforce a binary format that ships with header files (and method signatures), and enforce semantic versioning. If any library doesn't play by the semantic rules, don't let it publish. That's the authority and responsibility that NPM failed to include. If everybody plays by the semantic rules ... then libraries can be upgraded automatically without breaking anything. And a huge plus: They can be installed as _shared_ libraries, which is such an old concept that it hurts my fingers having to type its advantages.

OJFord 7y ago
How do you enforce it? Cargo (rust) considered it, using the vastly more information it has about whether signatures have changed than NPM, but rejected it because you can still make breaking changes without changing a function signature, so why claim to detect it if only a subset can be.
- edynoid 7y ago
  You can get pretty far with a statically typed, purely functional language. For example, Elm's package manager enforces semantic versioning: https://elm-lang.org/ https://elm-lang.org/ I don't think you can do that with JavaScript.
  - OJFord 7y ago
    You can always break an API with the values, however much you do with the types. Its effectiveness also varies with how much and well types are used - e.g. whether you return `String` or `Url` to begin with.

bdg 7y ago

Not updating now prevents you from being able to update later. The entire security thing. Not getting "free value" of performance fixes, bug fixes, new features, etc.

macrael 7y ago

The main reason is security. When a security vulnerability is patched in a new version of one of the libraries you use, you should upgrade, and if you haven't upgraded it in two years it is gonna be a pain in the ass. On one of our projects we've got what I think is the best take on this I've seen. Once a week, CI updates all our dependencies and makes fresh PR. That PR then goes through CI and can be merged by an engineer if it looks good.

tracer4201 7y ago

Security and availability. If you’re at a large company, not updating your dependencies could mean an outage, losing customer or other data you don’t want exposed to the world. A simpler way to state it is it could be the death of your company.

scotty79 7y ago

I always update libraries when I'm revisiting a project. This help me to engage with the project because the thing that motivates me most is if something doesn't work. And after updating libraries something usually doesn't.

knightofmars 7y ago

Because it is a major security issue to not keep up with library upgrades and general maintenance. It's in the OWASP top 10 for a reason. The Equifax breach is a perfect example of why ignoring library upgrades is a high risk behavior for any organization. https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top...