4 ms·

Not using toy libraries for production systems is a lesson every young developer learns early on in their career.

by jstarfish 8y ago

jacquesm 8y ago
Fortunately every young developer is also schooled extensively in telling toy libraries apart from serious ones.
- janoc 8y ago
  And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project? If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example? A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
  - jacquesm 8y ago
    > And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Some critical assumptions: - a more senior dev is available - has time - understand the system well enough to judge the impact - is actually a better developer than the junior (in spite of being older / in the game longer) > Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project? It isn't, that was the point. > If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example? Some critical assumptions: - organizations keep a close eye on developers incorporating code under various licenses - the people keeping an eye on that are qualified to make the calls - the resources to keep an eye on this are available > A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO. Sure. But that doesn't mean these things don't happen just about everywhere, many times per day. It is rare to find a company where all of the assumptions labelled above are true all the time. And that's where the problem lies. It's a clear case of there being no difference between theory and practice in theory but in practice there is, and rather a lot of it. Everybody knows in theory how software should be developed, but in practice hardly anybody actually does it that way. They're either out of time, options or qualifications (or all three) and they will do the job anyway. That doesn't excuse it, but it does help you to understand it.
  - rhizome 8y ago
    And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.
- gaius 8y ago
  Then explain nodejs and MongoDB existing in production systems? Or did you forget the /s...
  - jacquesm 8y ago
    > Or did you forget the /s... Yep. It's been a long day after a particularly long week. I will take a break from HN, too much on my mind. Thanks for the reminder.
    - gaius 8y ago
      Have a great weekend, catch you on the flipside
- jstarfish 8y ago
  By definition, they aren't though-- for the truly green, that extensive schooling comes from `npm/pip/gem install`ing random packages with implementations they don't understand or can't account for, then having to deal with the fallout in whatever form it chooses to manifest itself. Could be a maintainability nightmare, or it could be losing your job. My advice to mentees is that if installing a package to achieve x saves (a significant amount of) time/money that outweighs the risks to self/company or has value added by means of product maturity or domain expertise, then by all means do not roll your own crypto, web framework, db connector or machine learning library. But if one is going to introduce dependencies on things as trivial as leftpad or someone's Show HN single-pass weekend hackathon proof-of-concept, they will soon learn why we don't bring toys to work.
passiveincomelg 8y ago
In what parallel universe are you and how do I find the next wormhole to get there? :)
- janoc 8y ago
  Well, that people don't do such things is not really the fault (nor problem) of the developer of that toy library, IMO. Nobody else but you alone can ensure that your project is managed and developed properly.
Alex3917 8y ago
If you put something out there and no one uses it then fine. But once it has hundreds of commits and issues and over 1,000 stars on GitHub, then I think you have some responsibility to people using the thing you’ve created -- if you’ve been actively promoting it as something everyone should use.
- titanix2 8y ago
  No they aren’t. The code is open source anyway so if the dependency is important enough for your project, fork it. Or pay for support.
- jstarfish 8y ago
  It's a free product, not a child support obligation. Even if you do walk away, it's open source and can be maintained by anybody interested in stepping up. This is the price of adoption, not guaranteed updates for life from the creator. But I get where you're coming from. It's even worse on Steam, where developers will actually collect money during the "early access" phase and then walk away once a (closed-source) tech demo is half-complete.
  - Alex3917 8y ago
    > This is the price of adoption, not guaranteed updates for life from the creator. I’m not saying anyone should be obligated to do free work. This issue is that most people don’t feel comfortable publishing a public fork without the blessing of the creator, or at least knowing the creator no longer intends to work on the project in the near future. So you end up with these situations where there are thousands of people running production systems with unmerged security patches because the creator can’t be bothered to spend 30 seconds to write a one sentence reply to an email. Short of being in a coma, I consider that toxic behavior. And just to be clear I’m taking about situations where there are lots of open PRs but no signs of life for months or years on end, not situations where the creator just went on vacation for a few weeks.
    - lstodd 8y ago
      eww, that's called entitlement. no one promised you anything. you merged some code into your project. now deal with the consequences. be responsible for your work.

Not using toy libraries for production systems is a lesson every young developer learns early on in their career.

jacquesm 8y ago

Fortunately every young developer is also schooled extensively in telling toy libraries apart from serious ones.

janoc 8y ago
And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project? If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example? A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
- jacquesm 8y ago
  > And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Some critical assumptions: - a more senior dev is available - has time - understand the system well enough to judge the impact - is actually a better developer than the junior (in spite of being older / in the game longer) > Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project? It isn't, that was the point. > If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example? Some critical assumptions: - organizations keep a close eye on developers incorporating code under various licenses - the people keeping an eye on that are qualified to make the calls - the resources to keep an eye on this are available > A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO. Sure. But that doesn't mean these things don't happen just about everywhere, many times per day. It is rare to find a company where all of the assumptions labelled above are true all the time. And that's where the problem lies. It's a clear case of there being no difference between theory and practice in theory but in practice there is, and rather a lot of it. Everybody knows in theory how software should be developed, but in practice hardly anybody actually does it that way. They're either out of time, options or qualifications (or all three) and they will do the job anyway. That doesn't excuse it, but it does help you to understand it.
- rhizome 8y ago
  And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system? Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.
gaius 8y ago
Then explain nodejs and MongoDB existing in production systems? Or did you forget the /s...
- jacquesm 8y ago
  > Or did you forget the /s... Yep. It's been a long day after a particularly long week. I will take a break from HN, too much on my mind. Thanks for the reminder.
  - gaius 8y ago
    Have a great weekend, catch you on the flipside
jstarfish 8y ago
By definition, they aren't though-- for the truly green, that extensive schooling comes from `npm/pip/gem install`ing random packages with implementations they don't understand or can't account for, then having to deal with the fallout in whatever form it chooses to manifest itself. Could be a maintainability nightmare, or it could be losing your job. My advice to mentees is that if installing a package to achieve x saves (a significant amount of) time/money that outweighs the risks to self/company or has value added by means of product maturity or domain expertise, then by all means do not roll your own crypto, web framework, db connector or machine learning library. But if one is going to introduce dependencies on things as trivial as leftpad or someone's Show HN single-pass weekend hackathon proof-of-concept, they will soon learn why we don't bring toys to work.

passiveincomelg 8y ago

In what parallel universe are you and how do I find the next wormhole to get there? :)

janoc 8y ago
Well, that people don't do such things is not really the fault (nor problem) of the developer of that toy library, IMO. Nobody else but you alone can ensure that your project is managed and developed properly.

Alex3917 8y ago

If you put something out there and no one uses it then fine. But once it has hundreds of commits and issues and over 1,000 stars on GitHub, then I think you have some responsibility to people using the thing you’ve created -- if you’ve been actively promoting it as something everyone should use.

titanix2 8y ago
No they aren’t. The code is open source anyway so if the dependency is important enough for your project, fork it. Or pay for support.
jstarfish 8y ago
It's a free product, not a child support obligation. Even if you do walk away, it's open source and can be maintained by anybody interested in stepping up. This is the price of adoption, not guaranteed updates for life from the creator. But I get where you're coming from. It's even worse on Steam, where developers will actually collect money during the "early access" phase and then walk away once a (closed-source) tech demo is half-complete.
- Alex3917 8y ago
  > This is the price of adoption, not guaranteed updates for life from the creator. I’m not saying anyone should be obligated to do free work. This issue is that most people don’t feel comfortable publishing a public fork without the blessing of the creator, or at least knowing the creator no longer intends to work on the project in the near future. So you end up with these situations where there are thousands of people running production systems with unmerged security patches because the creator can’t be bothered to spend 30 seconds to write a one sentence reply to an email. Short of being in a coma, I consider that toxic behavior. And just to be clear I’m taking about situations where there are lots of open PRs but no signs of life for months or years on end, not situations where the creator just went on vacation for a few weeks.
  - lstodd 8y ago
    eww, that's called entitlement. no one promised you anything. you merged some code into your project. now deal with the consequences. be responsible for your work.