4 ms·

Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and pain

by Reedx 7y ago

Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.

cogman10 7y ago
Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it). Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here. I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because the version of lombok they brought in was old and for highly used library (so upgrading wasn't simple). If you can write the used functionality in 10 minutes, you should not bring it in as a dependency.
- nitrogen 7y ago
  If you can write the used functionality in 10 minutes, you should not bring it in as a dependency. I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.
  - nwallin 7y ago
    I think you are dramatically underestimating the cost of a dependency. The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies) The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The problem with importing the world is that you add a dynamic cost to simply existing without change. It's a tradeoff, and it's not a tradeoff that's consistent across organizations. For some orgs it's really important to be first to market. In other orgs it's important to not break shit for your existing customers. My org is well established in our field. Nothing matters more than retaining our existing customers. Importing a new lib requires approval from legal, which requires about a personweek. In other words, if one developer could implement the same thing in less than 40 hours, the developer should implement it themself. For us, a slow moving org, I think we're at the right place. For a startup, obviously not.
    - nitrogen 7y ago
      I think you may be dramatically underestimating the cost of NIH and code bloat. I'm talking about things developers think they can do in ten minutes but that they are at high risk of getting wrong: generating SQL, parsing JSON, handling dates, etc. These are all things that have well-established libraries in most sane languages (maybe NodeJS is not sane in this regard), where everything that you save yourself from by using the library is worth even a 40 hour review process.
      - cogman10 7y ago
        None of the examples you've given are 10 minute problems. It isn't reasonable to think of them as such and so it is a straw man. 10 minute problems are things like is-odd - https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd is-even - https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even leftpad - https://www.npmjs.com/package/pad https://www.npmjs.com/package/pad Or bringing in large libraries to use single methods or functions from them. Such as Bringing in gauva for max Bringing in apache commons for StringUtils.join. I've seen both examples in my company's code base. A library that does JSON parsing, date handling, etc is doing a lot more heavy lifting than "is-even".
chenning 7y ago
Painful lessons, yes. Instant gratification versus long-term planning. I think this applies to more than just software.

by Reedx 7y ago

Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.

cogman10 7y ago

Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it). Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here. I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because the version of lombok they brought in was old and for highly used library (so upgrading wasn't simple). If you can write the used functionality in 10 minutes, you should not bring it in as a dependency.

nitrogen 7y ago
If you can write the used functionality in 10 minutes, you should not bring it in as a dependency. I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.
- nwallin 7y ago
  I think you are dramatically underestimating the cost of a dependency. The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies) The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The problem with importing the world is that you add a dynamic cost to simply existing without change. It's a tradeoff, and it's not a tradeoff that's consistent across organizations. For some orgs it's really important to be first to market. In other orgs it's important to not break shit for your existing customers. My org is well established in our field. Nothing matters more than retaining our existing customers. Importing a new lib requires approval from legal, which requires about a personweek. In other words, if one developer could implement the same thing in less than 40 hours, the developer should implement it themself. For us, a slow moving org, I think we're at the right place. For a startup, obviously not.
  - nitrogen 7y ago
    I think you may be dramatically underestimating the cost of NIH and code bloat. I'm talking about things developers think they can do in ten minutes but that they are at high risk of getting wrong: generating SQL, parsing JSON, handling dates, etc. These are all things that have well-established libraries in most sane languages (maybe NodeJS is not sane in this regard), where everything that you save yourself from by using the library is worth even a 40 hour review process.
    - cogman10 7y ago
      None of the examples you've given are 10 minute problems. It isn't reasonable to think of them as such and so it is a straw man. 10 minute problems are things like is-odd - https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd is-even - https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even leftpad - https://www.npmjs.com/package/pad https://www.npmjs.com/package/pad Or bringing in large libraries to use single methods or functions from them. Such as Bringing in gauva for max Bringing in apache commons for StringUtils.join. I've seen both examples in my company's code base. A library that does JSON parsing, date handling, etc is doing a lot more heavy lifting than "is-even".

chenning 7y ago

Painful lessons, yes. Instant gratification versus long-term planning. I think this applies to more than just software.