6 ms·

This! I previously worked for a small software company that frequently got itself lost in the upgrade treadmill (its going to take N man months to upgrade under

This! I previously worked for a small software company that frequently got itself lost in the upgrade treadmill (its going to take N man months to upgrade underlying technology X/Y/Z to the latest versions). Yet in the end, I kept asking, what does technology X/Y/Z provide to the product that benefits the customer. Those questions frequently didn't have satisfying answers. So, your not the cool, forward looking engineer when you favor using a 5 year old toolchain to build your product. OTOH, your also the engineer that doesn't have to come in on weekends to debug the death march bug that ends up being a result of doing the upgrade.

draw_down 10y ago
Sure. But, have fun trying to get a new job when you're using 5 year old tech. In other words it's not just about pride or being one of the cool kids.
- genericone 10y ago
  So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
- golergka 10y ago
  Say that to Cobol devs.
  - chris_wot 10y ago
    If you do, say it loudly or they might not hear you.
- ehnto 10y ago
  I can see your viewpoint, but I have to say that trying to keep up with the tooling treadmill has many tradeoffs. If there is a new framework or tool to know about every few months and you change job every three, you will be spending all your time re-learning some strange new wheel and taking energy away from truly excelling at your current tool set. On top of that, if we chase the carrot of technology we will always be using tools that are less than a few years old. In otherwords, un-tested by time and immature code bases without useful ecosystems and best practices. RiotJS for example, there is a way it's designed to be used, and it is idealogicaly sound. But also naive. That way will evolve a lot over time as even just a small project revealed a dozen or so pain points to solve, that haven't yet been addressed by the community. But working on an older codebase, communities have usually solved a lot of those problems with process or ammendments, and there is a wealth of information available.
- madeofpalk 10y ago
  There's a middle ground - don't upgrade systems for the sake of upgrading, but maybe if you're building something new or working on a sideproject, investigate newer technologies.
- deleted 10y ago
  [deleted]
- vidarh 10y ago
  If you're going for a permanent job, sure, you're largely tied to what is advertised. If you're going for consulting gigs, no problem: Focus on selling solutions rather than specifics. Then afterwards offer up a solution based on new tech, and offer up a better alternative and explain how it solves their problems better.
- icebraining 10y ago
  You must be a frontend or mobile developer. On the server side using five year old tech is the mark of a proactive and daring company. Our code depends on Python 2.7 (released in 2010) and we still have to compile our own CPython every time we deploy on servers managed by the client.
  - Drdrdrq 10y ago
    I wish I could upvote you more - spot on!
  - cthalupa 10y ago
    This is less and less true in the new and excited cloud/devops world, for better or worse. There are plenty of companies that even on the server side are chasing the latest release cycle.
- pjmlp 10y ago
  The secret is to try to be a polyglot, not just get yourself into a silo, and also build up on people skills. Many companies don't bother one cannot use the very latest fad, but you can demonstrate proficiency in soft skills, for example.
pmontra 10y ago
Sometimes you have to upgrade because the old version goes EOL and you won't have support anymore. This is a problem even if you don't add features and it applies to open source too. Example: as soon as Rails 5 gets released, Rails 3.2 won't get any secuurity fix anymore. If the customer accepts the risk of running a system that could be exploited by automated attacks, all fine. If it's not, time to upgrade at least to Rails 4.2. They could also decide to check if the new vulnerabilities apply to their old version and patch it themselves, but it's probably more expensive and error prone. s/Rails/any other technology/
- vinceguidry 10y ago
  That sort of support doesn't just go away. It just stops being free. These guys will happily help you run 2.3 and 3.2 for as long as you want: https://railslts.com/ https://railslts.com/ Again, this usually holds for any reasonably popular stack.
- Drdrdrq 10y ago
  Sure, this happens occasionally, but more often you get an engineer who would like to upgrade just because there is some new version available. Who cares about stability, at least the bugs are new... :( At least that's my experience.
  - sanderjd 10y ago
    My experience is that more often the engineer knows the good reasons to upgrade but doesn't know how to articulate them to you, especially when you are known to be hostile to the idea of upgrading things.
    - Drdrdrq 10y ago
      Actually, I am an engineer, and I myself try to keep up with new technologies. But that doesn't mean I will use them just because they are new - in my mind that is additional risk. I have used my share of technologies which were made obsolete anyway, and it's no fun converting your codebase. But I guess the cool junior engineer who went to another company and left her old company taking care of her project using not-new-anymore / obsolete technology, doesn't care much about that. But I guess if she can't articulate why her newest technology stack is better, we should just switch?</rant>
pjmlp 10y ago
Spot on. As technical lead on some projects whenever someone comes will cool idea X, my question usually boils down to what is the business value of that idea. If it doesn't improve business in some specific way, it doesn't matter how cool it is, it will just produce costs (developer time * hourly rate) without any benefit to the bottom line.
- superuser2 10y ago
  ... and that's how technical debt happens.
  - sanderjd 10y ago
    And how "it's so hard for us to hire good developers!" happens.
    - pjmlp 10y ago
      It doesn't happen if the company is willing to pay what they deserve, instead of wanting to have them to work for the same low rates as the ones they are paying to some offshoring consulting partner the other side of the world. Or if they provide a work environment that makes one feel like coming to the office. Good developers care about many factors besides shiny toys.
      - izacus 10y ago
        Good developers will also prefer to be well paid and have a good environment while working with modern toys instead of MUMPS infested codebase. (This is not an argument in favor of running after every new technology immediately, but you'll have trouble hiring and keeping good development on a JavaEE 2 environment with SVN build system based on 1990 code practices.)
        deleted 10y ago
        [deleted]
        10y ago

draw_down 10y ago

Sure. But, have fun trying to get a new job when you're using 5 year old tech. In other words it's not just about pride or being one of the cool kids.

genericone 10y ago
So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
golergka 10y ago
Say that to Cobol devs.
- chris_wot 10y ago
  If you do, say it loudly or they might not hear you.
ehnto 10y ago
I can see your viewpoint, but I have to say that trying to keep up with the tooling treadmill has many tradeoffs. If there is a new framework or tool to know about every few months and you change job every three, you will be spending all your time re-learning some strange new wheel and taking energy away from truly excelling at your current tool set. On top of that, if we chase the carrot of technology we will always be using tools that are less than a few years old. In otherwords, un-tested by time and immature code bases without useful ecosystems and best practices. RiotJS for example, there is a way it's designed to be used, and it is idealogicaly sound. But also naive. That way will evolve a lot over time as even just a small project revealed a dozen or so pain points to solve, that haven't yet been addressed by the community. But working on an older codebase, communities have usually solved a lot of those problems with process or ammendments, and there is a wealth of information available.
madeofpalk 10y ago
There's a middle ground - don't upgrade systems for the sake of upgrading, but maybe if you're building something new or working on a sideproject, investigate newer technologies.
deleted 10y ago
[deleted]
vidarh 10y ago
If you're going for a permanent job, sure, you're largely tied to what is advertised. If you're going for consulting gigs, no problem: Focus on selling solutions rather than specifics. Then afterwards offer up a solution based on new tech, and offer up a better alternative and explain how it solves their problems better.
icebraining 10y ago
You must be a frontend or mobile developer. On the server side using five year old tech is the mark of a proactive and daring company. Our code depends on Python 2.7 (released in 2010) and we still have to compile our own CPython every time we deploy on servers managed by the client.
- Drdrdrq 10y ago
  I wish I could upvote you more - spot on!
- cthalupa 10y ago
  This is less and less true in the new and excited cloud/devops world, for better or worse. There are plenty of companies that even on the server side are chasing the latest release cycle.
pjmlp 10y ago
The secret is to try to be a polyglot, not just get yourself into a silo, and also build up on people skills. Many companies don't bother one cannot use the very latest fad, but you can demonstrate proficiency in soft skills, for example.

pmontra 10y ago

Sometimes you have to upgrade because the old version goes EOL and you won't have support anymore. This is a problem even if you don't add features and it applies to open source too. Example: as soon as Rails 5 gets released, Rails 3.2 won't get any secuurity fix anymore. If the customer accepts the risk of running a system that could be exploited by automated attacks, all fine. If it's not, time to upgrade at least to Rails 4.2. They could also decide to check if the new vulnerabilities apply to their old version and patch it themselves, but it's probably more expensive and error prone. s/Rails/any other technology/

vinceguidry 10y ago
That sort of support doesn't just go away. It just stops being free. These guys will happily help you run 2.3 and 3.2 for as long as you want: https://railslts.com/ https://railslts.com/ Again, this usually holds for any reasonably popular stack.
Drdrdrq 10y ago
Sure, this happens occasionally, but more often you get an engineer who would like to upgrade just because there is some new version available. Who cares about stability, at least the bugs are new... :( At least that's my experience.
- sanderjd 10y ago
  My experience is that more often the engineer knows the good reasons to upgrade but doesn't know how to articulate them to you, especially when you are known to be hostile to the idea of upgrading things.
  - Drdrdrq 10y ago
    Actually, I am an engineer, and I myself try to keep up with new technologies. But that doesn't mean I will use them just because they are new - in my mind that is additional risk. I have used my share of technologies which were made obsolete anyway, and it's no fun converting your codebase. But I guess the cool junior engineer who went to another company and left her old company taking care of her project using not-new-anymore / obsolete technology, doesn't care much about that. But I guess if she can't articulate why her newest technology stack is better, we should just switch?</rant>

pjmlp 10y ago

Spot on. As technical lead on some projects whenever someone comes will cool idea X, my question usually boils down to what is the business value of that idea. If it doesn't improve business in some specific way, it doesn't matter how cool it is, it will just produce costs (developer time * hourly rate) without any benefit to the bottom line.

superuser2 10y ago
... and that's how technical debt happens.
- sanderjd 10y ago
  And how "it's so hard for us to hire good developers!" happens.
  - pjmlp 10y ago
    It doesn't happen if the company is willing to pay what they deserve, instead of wanting to have them to work for the same low rates as the ones they are paying to some offshoring consulting partner the other side of the world. Or if they provide a work environment that makes one feel like coming to the office. Good developers care about many factors besides shiny toys.
    - izacus 10y ago
      Good developers will also prefer to be well paid and have a good environment while working with modern toys instead of MUMPS infested codebase. (This is not an argument in favor of running after every new technology immediately, but you'll have trouble hiring and keeping good development on a JavaEE 2 environment with SVN build system based on 1990 code practices.)
      - deleted 10y ago
        [deleted]
      - 10y ago