3 ms·

I hate shared code across entire companies. Someone will write a useful package, it'll be integrated into lots of teams code, and then the original package auth

I hate shared code across entire companies. Someone will write a useful package, it'll be integrated into lots of teams code, and then the original package author leaves. No one maintains their package. A year or two later someone wants to change it, but now no one knows where it's used, what the impact of the change will be, or even whose responsibility it is to manage and maintain the code. All shared code should have a maintainer, and the maintainer should be responsible for updates. If that person leaves then someone else should have to take over that responsibility. In the case of the problem in the article it should be a very simple matter of raising a high priority bug ticket to fix the issue, and the maintainer then informing users of the library that they need to update their dependencies. It never works like that though.

galaxyLogic 5y ago
> All shared code should have a maintainer, All code should have a maintainer.
- rurban 5y ago
  All shared code should have proper documentation (including which errors are thrown, plus unit-tests). Then every flyby can maintain it. A maintainer per se does not help at all, if it's a bad one. Most are bad
  - galaxyLogic 5y ago
    What I'm thinking is that you need code/module ownership. Every module should have an owner, who is its maintainer. Only that way maintainers get credit for doing great maintenance including providing good documentation. If everybody can "maintain" a piece of code nobody is really responsible for it and nobody really gets credit or blame because everybody does.
mgaunard 5y ago
I've worked with team leads who were against the idea of assigning maintainers/owners to specific packages, on the rationale that we didn't have enough people to do that (I still do not understand how that rationale works either). Instead you end up in a situation where everyone is responsible for everything, which also means everyone is responsible for nothing.
hermanradtke 5y ago
Everything is a trade off. The other extreme is having many libraries with overlapping concerns where the same security holes show up again and again. I think the real answer is to decide on a strategy and then put healthy process in place to mitigate the downsides. In the case of sharing code across the company, make sure there are 2+ maintainers. This sort of succession planning is common. It is not foolproof, but it does mitigate the issue you raised.
jiveturkey 5y ago
> no one knows where it's used ... Isn't this really a tooling problem? I can't imagine any environment in which I can't instantly find all callers/users of a shared package. The problem I always have is that there are too many [known] callers! Impact is still unknown because you can't always depend on unit and other test to uncover complex issues unforeseen and unknown until they actually crop up. But that's why you have a staging environment. It's better than the alternative of not sharing code.
- bigiain 5y ago
  > I can't imagine any environment in which I can't instantly find all callers/users of a shared package All the people who spent that last week or two hunting down places where log4j got imported by dependencies like Springboot or Grails are crying into their Xmas whisky at this…
  - samus 5y ago
    Had that job, and I disagree. Maven Dependency plugin has got you there. `dependency:tree` even shows you which library brought it along. The difficult part was how to make dependency versions from `log4j-bom` win over the `spring-boot-dependencies` BOM. Also, one or two places in the code actually used some utility functions from `log4j-core`...
    - Xylakant 5y ago
      But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer maintained that just left last week and that just happens to be deployed on an external facing web server. It’s easier for Java based apps since you can just scan the machines they’re deployed on, but it’s hard for C and the like.
      - samus 5y ago
        Yeah, there was also a deployable that ops almost forgot about, but I remembered. But even in C, you can inspect the symbol table of binaries. Unless they got stripped or optimized away, of course. Edit: yes, deployables that nobody knows about and just sit there for years are a huge problem.
cwilkes 5y ago
The only thing worse than shared code across the company is to not have any shared code across the company.
cranekam 5y ago
It’s better to solve these problems than have N copies of common libraries, each with their own subtle bugs, different interfaces, and so on. A very crude approach to solving this is to a) require code review from some core team for changes to common/, b) add lint checks to prevent project a importing code from project b (i.e. non-common code). Avoiding the problems one can run into with a shared codebase by not sharing at all is the worst solution.
zerocount 5y ago
There should be no shared code and all projects should be totally isolated from eachother. If you need shared code, fork it and maintain it to your needs.

galaxyLogic 5y ago

> All shared code should have a maintainer, All code should have a maintainer.

rurban 5y ago
All shared code should have proper documentation (including which errors are thrown, plus unit-tests). Then every flyby can maintain it. A maintainer per se does not help at all, if it's a bad one. Most are bad
- galaxyLogic 5y ago
  What I'm thinking is that you need code/module ownership. Every module should have an owner, who is its maintainer. Only that way maintainers get credit for doing great maintenance including providing good documentation. If everybody can "maintain" a piece of code nobody is really responsible for it and nobody really gets credit or blame because everybody does.

mgaunard 5y ago

I've worked with team leads who were against the idea of assigning maintainers/owners to specific packages, on the rationale that we didn't have enough people to do that (I still do not understand how that rationale works either). Instead you end up in a situation where everyone is responsible for everything, which also means everyone is responsible for nothing.

hermanradtke 5y ago

Everything is a trade off. The other extreme is having many libraries with overlapping concerns where the same security holes show up again and again. I think the real answer is to decide on a strategy and then put healthy process in place to mitigate the downsides. In the case of sharing code across the company, make sure there are 2+ maintainers. This sort of succession planning is common. It is not foolproof, but it does mitigate the issue you raised.

jiveturkey 5y ago

> no one knows where it's used ... Isn't this really a tooling problem? I can't imagine any environment in which I can't instantly find all callers/users of a shared package. The problem I always have is that there are too many [known] callers! Impact is still unknown because you can't always depend on unit and other test to uncover complex issues unforeseen and unknown until they actually crop up. But that's why you have a staging environment. It's better than the alternative of not sharing code.

bigiain 5y ago
> I can't imagine any environment in which I can't instantly find all callers/users of a shared package All the people who spent that last week or two hunting down places where log4j got imported by dependencies like Springboot or Grails are crying into their Xmas whisky at this…
- samus 5y ago
  Had that job, and I disagree. Maven Dependency plugin has got you there. `dependency:tree` even shows you which library brought it along. The difficult part was how to make dependency versions from `log4j-bom` win over the `spring-boot-dependencies` BOM. Also, one or two places in the code actually used some utility functions from `log4j-core`...
  - Xylakant 5y ago
    But the problem is the inverse one: given a library, which project in your org depends on it? Possibly a project tucked away into a repository that a developer maintained that just left last week and that just happens to be deployed on an external facing web server. It’s easier for Java based apps since you can just scan the machines they’re deployed on, but it’s hard for C and the like.
    - samus 5y ago
      Yeah, there was also a deployable that ops almost forgot about, but I remembered. But even in C, you can inspect the symbol table of binaries. Unless they got stripped or optimized away, of course. Edit: yes, deployables that nobody knows about and just sit there for years are a huge problem.

cwilkes 5y ago

The only thing worse than shared code across the company is to not have any shared code across the company.

cranekam 5y ago

It’s better to solve these problems than have N copies of common libraries, each with their own subtle bugs, different interfaces, and so on. A very crude approach to solving this is to a) require code review from some core team for changes to common/, b) add lint checks to prevent project a importing code from project b (i.e. non-common code). Avoiding the problems one can run into with a shared codebase by not sharing at all is the worst solution.

zerocount 5y ago

There should be no shared code and all projects should be totally isolated from eachother. If you need shared code, fork it and maintain it to your needs.