3 ms·

> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates

> It literally added weeks of man-hours to the project, per day. Can you explain what exactly you mean here, because the way I read it realistic time estimates for the projects grew by weeks pr day which probably means - I misread - you wrote something you didn't mean Anyways it sounds like something was way off and I have worked on some projects with Maven and other systems.

withinboredom 6y ago
Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.
- eitland 6y ago
  OK, so again not Mavens fault but an utterly insane bureaucracy? Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?
  - avereveard 6y ago
    I agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working on licensing and you don't want to waste legals just to run a package trough vuln scans software. beside, companies that care usually also have a database of previously cleared packages, so one can reduce one own work/delays by picking from the approved deps list.
    - eitland 6y ago
      50 hours pr top level dependency not once or twice or ten times but every time does however sound like something "cache-like" is missing on the human level?
      - avereveard 6y ago
        true I was reasoning more on the 4 hour per package, which is in line. but you're right for sure the unique dependency graph can't be averaging that high
- oauea 6y ago
  Yes, vetting everything takes a LOT of time. Regardless of the language, package manager, etc. We (small shop) don't vet the code of all of our dependencies, since we simply don't have the manpower. But we do run nexus to have the guarantee of version pinning. So something that is fine today will be fine in 5 years.

withinboredom 6y ago

Due to the amount of bureaucracy and vetting required, each package needed four people to touch the task, it took about an hour each person (four man-hours). Then you throw in their dependencies and it grew to about 50 man-hours per top-level dependency.

eitland 6y ago
OK, so again not Mavens fault but an utterly insane bureaucracy? Because otherwise the workload should shrink fast after one has vetted the dependecies for a couple of packages?
- avereveard 6y ago
  I agree on "not maven fault" but I don't find that much bureaucracy insane, for one changing dependencies on a mature java project doesn't happen that often, and for another knowing licensing, possible patent violation and a scan against a known vulnerabilities database is not a bad thing to do and it's normal for it to take some time as it passes hand between different people, after all you don't want devs working on licensing and you don't want to waste legals just to run a package trough vuln scans software. beside, companies that care usually also have a database of previously cleared packages, so one can reduce one own work/delays by picking from the approved deps list.
  - eitland 6y ago
    50 hours pr top level dependency not once or twice or ten times but every time does however sound like something "cache-like" is missing on the human level?
    - avereveard 6y ago
      true I was reasoning more on the 4 hour per package, which is in line. but you're right for sure the unique dependency graph can't be averaging that high
oauea 6y ago
Yes, vetting everything takes a LOT of time. Regardless of the language, package manager, etc. We (small shop) don't vet the code of all of our dependencies, since we simply don't have the manpower. But we do run nexus to have the guarantee of version pinning. So something that is fine today will be fine in 5 years.