5 ms·

I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most te

I keep saying it again and again: Dependencies strangle dev teams to death. A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. And I'll add that a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers around technologies that work more than well enough without, and that create even more problems for a dev who now has to understand both original and wrapper's attempt at enhancement. Enough wrapping! Create something real, just once.

nicoburns 5y ago
> A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. I definitely agree that the attitude of never upgrading dependencies doesn't work! But I've seen plenty of teams using dependencies successfully that took the opposite approach of updating them regularly (say, spending an hour updating versions every couple of weeks - perhaps a bit longer if there is a major release of an important dependency). This might not work if you require mission-critical stability, but it can work out to a huge time saving if you don't.
- jamesfinlayson 5y ago
  Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.
  - gregplaysguitar 5y ago
    I used to do this before I discovered renovate [1] - now we spend time working on major upgrades but minor are generally automatic (assuming they pass tests) [1]: https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate
    - jamesfinlayson 5y ago
      Oh nice - do you get many problems that slip through even though tests pass? I had a minor update to the Stripe SDK recently that broke something.
      - gregplaysguitar 5y ago
        We do get very occasional issues in our React app, but not enough to outweigh the benefits of things staying up to date.
random_kris 5y ago
Well with spring boot you can use spring wrappers but there are always (atleast in my expirience) ways to override their way of doing things or just completely skip their wrapper and just use whatever is under the hood
- commandlinefan 5y ago
  > completely skip their wrapper Why use Spring Boot at all then?
  - chaostheory 5y ago
    Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.
    - pooya72 5y ago
      What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.
      - random_kris 5y ago
        There is quite some boilerplate and for someone inexperienced it is quite a big leap. Ive been developing with spring for past 3 years and so far I freaking love it. Ive gotten quite quick with it so I can do an mvp with auth, logging, microservice patterns really fast. And when project grows in complexity it is very maintainable. But if you are not expirienced and don't care about maintainability and want something fast then node& express is a way to go imho
        pooya72 5y ago
        Thanks for your insight. I agree with your comment about the trade off between the time it takes to fully learn the framework vs the productivity that you will get. I think that’s true for all frameworks. There’s also Javelin if you need something smaller and quick to pick in Java that is similar to Express.js.
commandlinefan 5y ago
> a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers ... that don't usually add any real value.
jordiburgos 5y ago
But Spring also saves you the time of putting those wrapped technologies together.
- jjtheblunt 5y ago
  I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.
  - pooya72 5y ago
    What do you think people waste most of their time on?
    - zelphirkalt 5y ago
      Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.
      - deleted 5y ago
        [deleted]
      - pooya72 5y ago
        I'm sorry, put the parent comment was talking a the Java framework Spring. My question was in regard to that framework.
    - wtetzner 5y ago
      Debugging is one. I’ve spent and enormous amount of time debugging problems that never would have occurred without Spring, and even more debugging things that would have been much easier to debug without Spring. And even if I didn’t have to spend all that extra time debugging, I don’t think Spring actually added any real value.
Cthulhu_ 5y ago
I've been struggling with this for years in the front-end / JS space, to the point where I just want out and live happily in my reasonable Go dependency management / aversion space. It's a convoluted mess. A while ago I made the move to migrate to Yarn 2 / 3, because it uses less disk resources (dependencies are in .zip files). But because most tools still expect a node_modules folder, it required a lot of workarounds. And now I'm in some kind of dependency hell where one library needs version X of another lib while the other needs version Y, and they're not compatible or don't work well in my editor. It just keeps giving. Sigh.
- acemarke 5y ago
  FWIW my experience is that Yarn 2/3 work great, as long as you stick with the `node_modules` linker (which works the same way Yarn 1 and NPM always have, by extracting all packages to disk) instead of the "Plug 'n Play" option (which keeps all packages zipped up, and requires that Yarn own all filesystem access to decompress files on the fly).
meesterdude 5y ago
I think it's language dependent - no team i've been on has been strangled by dependencies, they've largely amplified development; and the tradeoff to address breaking changes when they come is worth it. But if you add dependencies, and don't make time to keep them up to date... you're going to have a bad time.

nicoburns 5y ago

> A massive framework tangle of interlocking dependencies is enough to default most teams to never-never-upgrade-land, even when struggling to compensate for a too-early release's flaws. I definitely agree that the attitude of never upgrading dependencies doesn't work! But I've seen plenty of teams using dependencies successfully that took the opposite approach of updating them regularly (say, spending an hour updating versions every couple of weeks - perhaps a bit longer if there is a major release of an important dependency). This might not work if you require mission-critical stability, but it can work out to a huge time saving if you don't.

jamesfinlayson 5y ago
Agreed - I drive-by minor version updates at every opportunity that I can because I know if I don't, things will get pretty painful sooner or later.
- gregplaysguitar 5y ago
  I used to do this before I discovered renovate [1] - now we spend time working on major upgrades but minor are generally automatic (assuming they pass tests) [1]: https://github.com/renovatebot/renovate https://github.com/renovatebot/renovate
  - jamesfinlayson 5y ago
    Oh nice - do you get many problems that slip through even though tests pass? I had a minor update to the Stripe SDK recently that broke something.
    - gregplaysguitar 5y ago
      We do get very occasional issues in our React app, but not enough to outweigh the benefits of things staying up to date.

random_kris 5y ago

Well with spring boot you can use spring wrappers but there are always (atleast in my expirience) ways to override their way of doing things or just completely skip their wrapper and just use whatever is under the hood

commandlinefan 5y ago
> completely skip their wrapper Why use Spring Boot at all then?
- chaostheory 5y ago
  Because it provides commodity functionality that most developers with Spring experience can understand quicker, along with the Java philosophy of customization over convention. I don’t like Java or Spring, but I understand their benefits and why people like them.
  - pooya72 5y ago
    What don’t you like, if you don’t me asking? I was thinking of delving deeply into Spring.
    - random_kris 5y ago
      There is quite some boilerplate and for someone inexperienced it is quite a big leap. Ive been developing with spring for past 3 years and so far I freaking love it. Ive gotten quite quick with it so I can do an mvp with auth, logging, microservice patterns really fast. And when project grows in complexity it is very maintainable. But if you are not expirienced and don't care about maintainability and want something fast then node& express is a way to go imho
      - pooya72 5y ago
        Thanks for your insight. I agree with your comment about the trade off between the time it takes to fully learn the framework vs the productivity that you will get. I think that’s true for all frameworks. There’s also Javelin if you need something smaller and quick to pick in Java that is similar to Express.js.

commandlinefan 5y ago

> a lot of frameworks (I'm thinking of Spring here) devote most of their effort to creating "value add" wrappers ... that don't usually add any real value.

jordiburgos 5y ago

But Spring also saves you the time of putting those wrapped technologies together.

jjtheblunt 5y ago
I wonder if Spring has caused more wasted time, configuring its grandiosity, than it has saved people, and I say that because I don't know the answer.
- pooya72 5y ago
  What do you think people waste most of their time on?
  - zelphirkalt 5y ago
    Debugging and finding tiny mistakes in the new hot JS framework of the month. That and maybe trying to do something with CSS the wrong way, but not looking up how it should be done and reworking their DOM to make that happen.
    - deleted 5y ago
      [deleted]
    - pooya72 5y ago
      I'm sorry, put the parent comment was talking a the Java framework Spring. My question was in regard to that framework.
  - wtetzner 5y ago
    Debugging is one. I’ve spent and enormous amount of time debugging problems that never would have occurred without Spring, and even more debugging things that would have been much easier to debug without Spring. And even if I didn’t have to spend all that extra time debugging, I don’t think Spring actually added any real value.

Cthulhu_ 5y ago

I've been struggling with this for years in the front-end / JS space, to the point where I just want out and live happily in my reasonable Go dependency management / aversion space. It's a convoluted mess. A while ago I made the move to migrate to Yarn 2 / 3, because it uses less disk resources (dependencies are in .zip files). But because most tools still expect a node_modules folder, it required a lot of workarounds. And now I'm in some kind of dependency hell where one library needs version X of another lib while the other needs version Y, and they're not compatible or don't work well in my editor. It just keeps giving. Sigh.

acemarke 5y ago
FWIW my experience is that Yarn 2/3 work great, as long as you stick with the `node_modules` linker (which works the same way Yarn 1 and NPM always have, by extracting all packages to disk) instead of the "Plug 'n Play" option (which keeps all packages zipped up, and requires that Yarn own all filesystem access to decompress files on the fly).

meesterdude 5y ago

I think it's language dependent - no team i've been on has been strangled by dependencies, they've largely amplified development; and the tradeoff to address breaking changes when they come is worth it. But if you add dependencies, and don't make time to keep them up to date... you're going to have a bad time.