3 ms·

One could argue that LTS software is just a trap (and a particularly lucrative one). I know that this is likely a couple factors that allow me to say this namel

One could argue that LTS software is just a trap (and a particularly lucrative one). I know that this is likely a couple factors that allow me to say this namely 1. I can rule over our dependency and technology choices with an iron fist if need be 2. I live in on post 3.6+ Python as our main language and for anyone with good CD/CI you can always run your tests against the master branch and latest dev builds at least one or two versions ahead Okay so with that said, I feel like LTS versions of software are a trap for this reason. You end up in situations where there is so much pain with upgrading that you end up spending more either more time slogging through incompatibilities in the upgrade pipeline the longer you put it off the worst this gets, or you end up in situations where you have to maintain a forked Verizon’s if the code base while you upgrade things or you have to do a lot of monkey patching and work around to just get things running (famously this is the approach GitHub used to upgrade from different versions of Rails) The alternative is to pay money to companies that will maintain the version of what you are using, but even then you inevitably have to move forward and that leads to nasty vendor lock in I personally believe that having a robust CD/CI platform and a well tested code base allows you to by pass this whole charade. We always have our code tested against the next next incremental release in testing, the next versions dev branch and a rolling git pull and build that tests our code base. We really do expect things to break but it lets us plan with our working code quite accurately to avoid this problem altogether and now we largely update pretty close to release cadence. I don’t know if this helps anyone but I suggest doing software development in this fashion will save you a ton of headache. Being up to date with rolling release strategies has helped our productivity immensely because we can think about our dependencies and we have really whittled down to just a few core ones l. At a certain point we also formed some of the smaller ones and find maintaining those ourselves has been a flawless experience

cwyers 8y ago
Not upgrading your dependencies in-line with upstream is a form of perverse technical debt -- perverse because most technical debt is incurred to get new features/releases quicker, whereas the technical debt from not upgrading is incurred to simply stay where you are.
- mikekchar 8y ago
  People really don't understand the cost of bit rot -- especially business people. If it worked 10 years ago, and it hasn't changed, why can't we use it now? I happen to have an old Rails project that my team has to maintain. Rails 2, Ruby 1.8.7. When we stopped being able to even compile Ruby 1.8.7 with the latest versions of GCC, I finally got approval to upgrade. Things that business people can't understand is that nobody supports the language version any more and you can't build it with modern tools. You can't run the old OS any more, which has the old tools to build your code because the OS doesn't run on new hardware. I've been in the situation where I've had a server that was practically unique. It was so old that the only hardware that could run it, was the machine that was already running it. If that died, it was game over. (I should probably mention that I tend to specialise in difficult legacy situations in my career ;-) ). The idea that you need to do maintenance work on your software, even without fixing bugs and without adding features, is incredibly difficult for business people to swallow. So they naively allow the situation to get very, very bad (and then they have to hire someone like me).
  - cwyers 8y ago
    Right. If you stick with the herd, it's easy to find other people who are in your situation and share the burden of upkeep. Sticking on a platform past its prime means taking on a far larger share of the support burden yourself.

cwyers 8y ago

Not upgrading your dependencies in-line with upstream is a form of perverse technical debt -- perverse because most technical debt is incurred to get new features/releases quicker, whereas the technical debt from not upgrading is incurred to simply stay where you are.

mikekchar 8y ago
People really don't understand the cost of bit rot -- especially business people. If it worked 10 years ago, and it hasn't changed, why can't we use it now? I happen to have an old Rails project that my team has to maintain. Rails 2, Ruby 1.8.7. When we stopped being able to even compile Ruby 1.8.7 with the latest versions of GCC, I finally got approval to upgrade. Things that business people can't understand is that nobody supports the language version any more and you can't build it with modern tools. You can't run the old OS any more, which has the old tools to build your code because the OS doesn't run on new hardware. I've been in the situation where I've had a server that was practically unique. It was so old that the only hardware that could run it, was the machine that was already running it. If that died, it was game over. (I should probably mention that I tend to specialise in difficult legacy situations in my career ;-) ). The idea that you need to do maintenance work on your software, even without fixing bugs and without adding features, is incredibly difficult for business people to swallow. So they naively allow the situation to get very, very bad (and then they have to hire someone like me).
- cwyers 8y ago
  Right. If you stick with the herd, it's easy to find other people who are in your situation and share the burden of upkeep. Sticking on a platform past its prime means taking on a far larger share of the support burden yourself.