3 ms·

> Upgrade early and upgrade often It seems daft to keep seeing this lesson being learned by tech companies, and keep seeing blog posts where most of the pain

> Upgrade early and upgrade often It seems daft to keep seeing this lesson being learned by tech companies, and keep seeing blog posts where most of the pain would have been handled easily by just making upgrading a key feature. Instead, tech managers and engineers seem to make the same mistakes over and over again, delaying those upgrades, until suddenly they discover it's a hard task to upgrade. I get delaying to _some_ degree, it's better to let other people figure out those sharp bits on the bleeding edge for you, but you need to set an explicit target for upgrading. At another large tech company I worked for, it took the security team swinging the sledgehammer to get teams to upgrade from known-vulnerable versions of Ruby on Rails. When they came to do it, they discovered the changes were so extreme that the effort involved in migrating was likely more than the effort involved in a complete re-write (they did at least have pretty comprehensive tests)

cortesoft 8y ago
It is easy to say that in the abstract, but you always have a finite time/resource budget for doing work. Effort spent upgrading is effort not spent doing other important work. Is the other work more important in the long run? The answer is not trivial to answer. This is why we call it 'tech debt'.. it is just like any other debt. You take it on because you don't have the current resources to avoid it, and you calculate that it is worth taking it on. But then, you are carrying the interest on it, and if you aren't careful it will grow to be unmanageable, and all your dev effort goes into just paying the interest without paying the principle.
- Twirrim 8y ago
  It absolutely matters. Security is a feature. If you see upgrading as merely technical debt, you're never going to give it the appropriate attention.
  - regularfry 8y ago
    To twist the metaphor slightly, it's technical inflation.
  - Nagyman 8y ago
    Hrm, your statement seems to suggest upgraded versions are primarily security updates. Good projects backport security updates (for LTS versions anyway), and new versions with new features come with their own new security issues.
    - Twirrim 8y ago
      > Hrm, your statement seems to suggest upgraded versions are primarily security updates Not in the slightest. But security updates are part of them. > Good projects backport security updates (for LTS versions anyway), and new versions with new features come with their own new security issues. There's a limit to how far back patches go, even on the good projects. Rails 3.2 hasn't received a patch in over 2 and a half years, and while there is some desire to backport security fixes, you're dependent on a single individual having spare time to work on it, where more up-to-date releases receive patches far faster, and are far easier to test and integrate in to your existing platform. I've seen teams, and heard of companies, that are still running services on top of Rails 2 and the like. Now when they look at upgrading Rails the sheer number of changes is mind-boggling, and often represents a non-starter. I'm certainly not arguing to keep up on the bleeding edge, but making routine upgrading part of your regular workflow is most definitely an important part of remaining secure.
  - cortesoft 8y ago
    I never said it wasn’t a feature, just that not upgrading is a form of technical debt, with all the same reasons for existing and sticking around.
mikemotherwell 8y ago
Someone I saw on Twitter (I forget who - apologies) suggested DepOpps - short for "Dependency Opps" - as a job role, which was defined as a person dedicated to keeping a apps dependencies up to date. I doubt anyone would enjoy that gig, but it would be a very useful person to have in almost any multi-person team.

cortesoft 8y ago

It is easy to say that in the abstract, but you always have a finite time/resource budget for doing work. Effort spent upgrading is effort not spent doing other important work. Is the other work more important in the long run? The answer is not trivial to answer. This is why we call it 'tech debt'.. it is just like any other debt. You take it on because you don't have the current resources to avoid it, and you calculate that it is worth taking it on. But then, you are carrying the interest on it, and if you aren't careful it will grow to be unmanageable, and all your dev effort goes into just paying the interest without paying the principle.

Twirrim 8y ago
It absolutely matters. Security is a feature. If you see upgrading as merely technical debt, you're never going to give it the appropriate attention.
- regularfry 8y ago
  To twist the metaphor slightly, it's technical inflation.
- Nagyman 8y ago
  Hrm, your statement seems to suggest upgraded versions are primarily security updates. Good projects backport security updates (for LTS versions anyway), and new versions with new features come with their own new security issues.
  - Twirrim 8y ago
    > Hrm, your statement seems to suggest upgraded versions are primarily security updates Not in the slightest. But security updates are part of them. > Good projects backport security updates (for LTS versions anyway), and new versions with new features come with their own new security issues. There's a limit to how far back patches go, even on the good projects. Rails 3.2 hasn't received a patch in over 2 and a half years, and while there is some desire to backport security fixes, you're dependent on a single individual having spare time to work on it, where more up-to-date releases receive patches far faster, and are far easier to test and integrate in to your existing platform. I've seen teams, and heard of companies, that are still running services on top of Rails 2 and the like. Now when they look at upgrading Rails the sheer number of changes is mind-boggling, and often represents a non-starter. I'm certainly not arguing to keep up on the bleeding edge, but making routine upgrading part of your regular workflow is most definitely an important part of remaining secure.
- cortesoft 8y ago
  I never said it wasn’t a feature, just that not upgrading is a form of technical debt, with all the same reasons for existing and sticking around.

mikemotherwell 8y ago

Someone I saw on Twitter (I forget who - apologies) suggested DepOpps - short for "Dependency Opps" - as a job role, which was defined as a person dedicated to keeping a apps dependencies up to date. I doubt anyone would enjoy that gig, but it would be a very useful person to have in almost any multi-person team.