6 ms·

You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss abou

You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss about dependency management rather than use (flawed) industry standard tools and get to work on features. No one gets fired for using npm, you might get fired for insisting you build your own dependency management system because npm is insecure rather than working on your team's domain problem.

austincheney 6y ago
> No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.
- ritchiea 6y ago
  Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.
  - austincheney 6y ago
    It isn't about writing your own package manager. At least start with not using every package offered by NPM or dependencies that do. If you cannot attest to every package in your dependency tree you have failed dependency management.
    - ritchiea 6y ago
      Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager. Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience. This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.
      - throwaheyy 6y ago
        Who said anything about requiring a full code audit? Parent post is suggesting being selective about which packages you consume and which third-party developers you trust, including transitive dependencies pulled in by any package you consume.
        HereBeBeasties 6y ago
        I just don't think that's realistic for the JavaScript ecosystem, for the majority of projects. E.g. The weight of something "standard" like create-react-app.
  - GrinningFool 6y ago
    Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to. It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to give the additional ongoing levels of scrutiny. I'm not hopeful that this will happen at large in the industry, though I know it _is_ happening within individual companies and projects. I'm sure we'll mitigate the damage to some extent by making package managers smarter and implementing finer-grained permissions. That will improve the situation over time, but it also takes us in the wrong direction by allowing us to forget that when we're shipping dependencies, we ultimately own their behavior.
    - ritchiea 6y ago
      It's a practice that's so ingrained and so taken for granted that I suspect it will not change unless a big popular package gets hacked and the vulnerability effects a significant portion of apps written in a popular language like Javascript or Python. And I'm not really arguing against vetting your dependencies or improving dependency management. I'm just saying in the real world, that if I made this particular imperfection in software development practices my hill to die on at work, there's a 99% chance it is not good for me or my career. So my options are, swim with the tide knowing we're doing things imperfectly, or fight an uphill battle for a more perfect world knowing that unless we avoid some major vulnerability every other Javascript developer falls victim to, there will be many eyes in my office staring over at me wondering if my extra caution is really worth the company's investment. If I keep my job at all. I want to write great software, but to do that, I need to actually have a job writing software. And until I get a job at Google or Facebook or Amazon (none of those being places I've ever actually applied to) I am generally working in conditions without the resources to do the kind of dependency vetting we're talking about in this thread.
      - m01 6y ago
        It might be ingrained these days, but this StackOverflow question asking for a package manager for C++ and not really getting any "obvious" answers is just under 10 years old: https://stackoverflow.com/q/7266097/1298153 https://stackoverflow.com/q/7266097/1298153. Conan.io's first commit was in 2015. You could also treat supply chain attacks on software dependencies like another IT security risk your company is exposed to (just like virus infection, ransomware attacks, phishing, etc) and go through the same thinking (and if appropriate other) processes to manage them. The company can then make a conscious decision on whether it's worth investing in mitigating, eliminating or accepting the risk. There's lots of information out there on dealing with cyber security risks, e.g. https://www.ncsc.gov.uk/collection/risk-management-collection/essential-topics/introduction-risk-management-cyber-security-guidance https://www.ncsc.gov.uk/collection/risk-management-collectio.... (Apologies if this is all obvious, I'm just trying to highlight an alternative approach which might help you deal with the dilemma and not have to "solve" it all by yourself)
- majormajor 6y ago
  Most devs would, however, end up owning the consequences of fully vetting their dependency tree when their manager gives them a terrible performance review for taking 20 times longer to do everything else than their peers. This can't change bottom up. Even if you went the professional licensing route you'd need top-down regulation to force companies to only higher vetted and licensed professionals, and to actually do verification of projects to make sure all your best practices were being followed and following up on penalizing developers who weren't.

austincheney 6y ago

> No one gets fired for using npm Most developers are eager to accept any resulting consequences because they don't own the consequences and because they are fearful of writing original code.

ritchiea 6y ago
Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.
- austincheney 6y ago
  It isn't about writing your own package manager. At least start with not using every package offered by NPM or dependencies that do. If you cannot attest to every package in your dependency tree you have failed dependency management.
  - ritchiea 6y ago
    Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager. Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience. This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.
    - throwaheyy 6y ago
      Who said anything about requiring a full code audit? Parent post is suggesting being selective about which packages you consume and which third-party developers you trust, including transitive dependencies pulled in by any package you consume.
      - HereBeBeasties 6y ago
        I just don't think that's realistic for the JavaScript ecosystem, for the majority of projects. E.g. The weight of something "standard" like create-react-app.
- GrinningFool 6y ago
  Currently, managing dependencies correctly by vetting them with each and every version bump is huge amount of overhead and it grows with each dependency pulled in. The way we as an industry have been handling it has largely been to keep going like we don't need to. It's going to keep getting worse until a) developers and project managers realize doing inherently unsafe things is bad and b) they have the resources to give the additional ongoing levels of scrutiny. I'm not hopeful that this will happen at large in the industry, though I know it _is_ happening within individual companies and projects. I'm sure we'll mitigate the damage to some extent by making package managers smarter and implementing finer-grained permissions. That will improve the situation over time, but it also takes us in the wrong direction by allowing us to forget that when we're shipping dependencies, we ultimately own their behavior.
  - ritchiea 6y ago
    It's a practice that's so ingrained and so taken for granted that I suspect it will not change unless a big popular package gets hacked and the vulnerability effects a significant portion of apps written in a popular language like Javascript or Python. And I'm not really arguing against vetting your dependencies or improving dependency management. I'm just saying in the real world, that if I made this particular imperfection in software development practices my hill to die on at work, there's a 99% chance it is not good for me or my career. So my options are, swim with the tide knowing we're doing things imperfectly, or fight an uphill battle for a more perfect world knowing that unless we avoid some major vulnerability every other Javascript developer falls victim to, there will be many eyes in my office staring over at me wondering if my extra caution is really worth the company's investment. If I keep my job at all. I want to write great software, but to do that, I need to actually have a job writing software. And until I get a job at Google or Facebook or Amazon (none of those being places I've ever actually applied to) I am generally working in conditions without the resources to do the kind of dependency vetting we're talking about in this thread.
    - m01 6y ago
      It might be ingrained these days, but this StackOverflow question asking for a package manager for C++ and not really getting any "obvious" answers is just under 10 years old: https://stackoverflow.com/q/7266097/1298153 https://stackoverflow.com/q/7266097/1298153. Conan.io's first commit was in 2015. You could also treat supply chain attacks on software dependencies like another IT security risk your company is exposed to (just like virus infection, ransomware attacks, phishing, etc) and go through the same thinking (and if appropriate other) processes to manage them. The company can then make a conscious decision on whether it's worth investing in mitigating, eliminating or accepting the risk. There's lots of information out there on dealing with cyber security risks, e.g. https://www.ncsc.gov.uk/collection/risk-management-collection/essential-topics/introduction-risk-management-cyber-security-guidance https://www.ncsc.gov.uk/collection/risk-management-collectio.... (Apologies if this is all obvious, I'm just trying to highlight an alternative approach which might help you deal with the dilemma and not have to "solve" it all by yourself)
majormajor 6y ago
Most devs would, however, end up owning the consequences of fully vetting their dependency tree when their manager gives them a terrible performance review for taking 20 times longer to do everything else than their peers. This can't change bottom up. Even if you went the professional licensing route you'd need top-down regulation to force companies to only higher vetted and licensed professionals, and to actually do verification of projects to make sure all your best practices were being followed and following up on penalizing developers who weren't.