3 ms·

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 responsibi

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.

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.