4 ms·

Consider how many layers of dependencies are in use today, and you have no idea who the commenter is, what position he has in the business you assume he is 'run

Consider how many layers of dependencies are in use today, and you have no idea who the commenter is, what position he has in the business you assume he is 'running'.

pferde 8y ago
If they're running that business, they are either paying people who can tell them the dependencies (if not, those people are being paid too much), or they are responsible for the code themselves (small co. or early startup), and should already know, or with small effort be able to identify all the dependencies whenever necessary. Anything else would be irresponsible. If they're not running that business and have enough access to the code to be able to use this service, they're probably a developer who again should be able to know about the dependencies. Or perhaps they're in a different position, and only want to know about this for curiosity's sake - in which case, I guess this could be useful. But still, you should be able to ask about this in-house. And as for the "layers" argument - if there are too many layers of dependencies to keep track of, something is very, very wrong with the technology you are using. (And yes, I do consider modern web tech completely insane.)
- Vinnl 8y ago
  Which technology are you using that does not have this problem?
  - ajdlinux 8y ago
    I work on the opposite end from the web stack - firmware development - and even we have layers upon layers of dependencies that are problematic to track.
    - pferde 8y ago
      The point is not that the deps are problematic to track - that is to be expected with any larger project. The point is actually doing the tracking, and being aware when the deps change, new one gets added, etc., and being able to determine what it means for the business.
      - Vinnl 8y ago
        So what technology are you using that makes that viable?
        pferde 8y ago
        Any today's technology, if you care about having your bases covered. Many people don't as I gathered (with great surprise, too) from this subthread.
- anoncoward111 8y ago
  I currently am helping to run a kitchen at a restaurant in my spare time and I can tell you that nobody including myself can tell you where our onions are grown, but that they come from Costco
  - pferde 8y ago
    There are grocery stores which specialize in being able to tell the customer exactly where their produce comes from. They've been quite in vogue these past years. :)
    - anoncoward111 8y ago
      Interestingly enough, it's debatable how useful this info is, sort of like how it's debatable knowing every single dependency for your project :)
- Cederfjard 8y ago
  >And as for the "layers" argument - if there are too many layers of dependencies to keep track of, something is very, very wrong with the technology you are using. (And yes, I do consider modern web tech completely insane.) So you were basically being glib about the salaries, since you know a lot of us are in that position? What do you suggest we do? When I list the dependency tree of our project at work I get ~5500 unique packages (many are different versions of the same ones). Does the fact that I don't know them by heart mean that I'm being paid too much?
  - pferde 8y ago
    No, if anything, I think anyone working in your field is not being paid enough for working with something as bonkers crazy. :) But seriously, I haven't said that you have to be able to recite the dependencies when woken up at night, just that you should have an existing internal methods of keeping track of them and auditing them, and not relying on some comes-one-day-disappears-the-next web service.
    - JanisL 8y ago
      I think this is why a lot of people vendor dependencies and keep mirrors of anything particularly mission critical that they depend on. I've been involved in situations where this has been done for closed source code too via escrow services to make sure of continuity of product even if the other business closes for whatever reason.
- JanisL 8y ago
  Consider something like PyPi and the way in which it will host Python packages. There's times with Python that you will not know what packages are dependencies until you actually download it (this you may notice is why Pipenv will take so long to create a lock file, it has to download a ton of packages, get our your network traffic tools and have a look sometime). So I'm fairly sure there are times where the reason you don't know the dependencies exactly is because they are in some form of being unknowable. Now you might argue that such systems should be re-implemented and as a generalized goal taken in isolation I would tend to agree (improving existing code including legacy systems is something we consult on in my company). But alas in existing systems you sometimes have to deal with non-ideal circumstances that were created with non-ideal package management tools (legacy python and c++ being prime examples of difficult areas to get 100% right).
JanisL 8y ago
I'd probably be best described as some combination of a technical manager and a businessman. I write some code but there's people I work with who are much better technologists than I am. A few years back I wrote a cross platform make replacement due to issues with an existing recursive make solution not getting dependencies right due to issues with it creating the wrong DAG (http://lcgapp.cern.ch/project/architecture/recursive_make.pdf http://lcgapp.cern.ch/project/architecture/recursive_make.pd...). The recursive solution was used in the first place because it was fast but it happened to be incorrect (interesting how stuff like Pipenv has really long lock times because it's prioritizing correctness). So I have an awareness of some of the difficulties in this space very directly. Before I did some projects with build systems and packaging there were a lot of things I didn't know I didn't know.

Consider how many layers of dependencies are in use today, and you have no idea who the commenter is, what position he has in the business you assume he is 'running'.

pferde 8y ago

If they're running that business, they are either paying people who can tell them the dependencies (if not, those people are being paid too much), or they are responsible for the code themselves (small co. or early startup), and should already know, or with small effort be able to identify all the dependencies whenever necessary. Anything else would be irresponsible. If they're not running that business and have enough access to the code to be able to use this service, they're probably a developer who again should be able to know about the dependencies. Or perhaps they're in a different position, and only want to know about this for curiosity's sake - in which case, I guess this could be useful. But still, you should be able to ask about this in-house. And as for the "layers" argument - if there are too many layers of dependencies to keep track of, something is very, very wrong with the technology you are using. (And yes, I do consider modern web tech completely insane.)

Vinnl 8y ago
Which technology are you using that does not have this problem?
- ajdlinux 8y ago
  I work on the opposite end from the web stack - firmware development - and even we have layers upon layers of dependencies that are problematic to track.
  - pferde 8y ago
    The point is not that the deps are problematic to track - that is to be expected with any larger project. The point is actually doing the tracking, and being aware when the deps change, new one gets added, etc., and being able to determine what it means for the business.
    - Vinnl 8y ago
      So what technology are you using that makes that viable?
      - pferde 8y ago
        Any today's technology, if you care about having your bases covered. Many people don't as I gathered (with great surprise, too) from this subthread.
anoncoward111 8y ago
I currently am helping to run a kitchen at a restaurant in my spare time and I can tell you that nobody including myself can tell you where our onions are grown, but that they come from Costco
- pferde 8y ago
  There are grocery stores which specialize in being able to tell the customer exactly where their produce comes from. They've been quite in vogue these past years. :)
  - anoncoward111 8y ago
    Interestingly enough, it's debatable how useful this info is, sort of like how it's debatable knowing every single dependency for your project :)
Cederfjard 8y ago
>And as for the "layers" argument - if there are too many layers of dependencies to keep track of, something is very, very wrong with the technology you are using. (And yes, I do consider modern web tech completely insane.) So you were basically being glib about the salaries, since you know a lot of us are in that position? What do you suggest we do? When I list the dependency tree of our project at work I get ~5500 unique packages (many are different versions of the same ones). Does the fact that I don't know them by heart mean that I'm being paid too much?
- pferde 8y ago
  No, if anything, I think anyone working in your field is not being paid enough for working with something as bonkers crazy. :) But seriously, I haven't said that you have to be able to recite the dependencies when woken up at night, just that you should have an existing internal methods of keeping track of them and auditing them, and not relying on some comes-one-day-disappears-the-next web service.
  - JanisL 8y ago
    I think this is why a lot of people vendor dependencies and keep mirrors of anything particularly mission critical that they depend on. I've been involved in situations where this has been done for closed source code too via escrow services to make sure of continuity of product even if the other business closes for whatever reason.
JanisL 8y ago
Consider something like PyPi and the way in which it will host Python packages. There's times with Python that you will not know what packages are dependencies until you actually download it (this you may notice is why Pipenv will take so long to create a lock file, it has to download a ton of packages, get our your network traffic tools and have a look sometime). So I'm fairly sure there are times where the reason you don't know the dependencies exactly is because they are in some form of being unknowable. Now you might argue that such systems should be re-implemented and as a generalized goal taken in isolation I would tend to agree (improving existing code including legacy systems is something we consult on in my company). But alas in existing systems you sometimes have to deal with non-ideal circumstances that were created with non-ideal package management tools (legacy python and c++ being prime examples of difficult areas to get 100% right).

JanisL 8y ago

I'd probably be best described as some combination of a technical manager and a businessman. I write some code but there's people I work with who are much better technologists than I am. A few years back I wrote a cross platform make replacement due to issues with an existing recursive make solution not getting dependencies right due to issues with it creating the wrong DAG (http://lcgapp.cern.ch/project/architecture/recursive_make.pdf http://lcgapp.cern.ch/project/architecture/recursive_make.pd...). The recursive solution was used in the first place because it was fast but it happened to be incorrect (interesting how stuff like Pipenv has really long lock times because it's prioritizing correctness). So I have an awareness of some of the difficulties in this space very directly. Before I did some projects with build systems and packaging there were a lot of things I didn't know I didn't know.