7 ms·

Just curious, why do you think that inter-project secrecy within a company is a bad idea?

by neuland 7y ago

markdown 7y ago
For the same reason that inter-agency secrecy contributed to the success (for the terrorists) of the 9/11 attacks.
- lostgame 7y ago
  You mean the departments of government that planned and staged 9/11 didn’t communicate with the departments that would have to believe the cover story? I mean, that makes sense, why would they? I mean, why would a government stage an attack against its own people, anyways? Oh, right. Oil and war profits.
  - enraged_camel 7y ago
    >>You mean the departments of government that planned and staged 9/11 Holy molly. We're spouting insane conspiracy theories on this site, now?
    - miopa 7y ago
      9/11 was a conspiracy. But because the official theory about it is very shaky, alternative theories (some insane, some not so much) are bound to sprout.
    - IOT_Apprentice 7y ago
      No, it is simpler. US intelligence agencies pre-911 did not share intelligence or pass along warnings across agency boundaries. That meant events such as the terrorists that went to flight school in Florida, did not get passed along to other agencies. It is why post-911 there is a DNI. However, when you have a chaos president, who distrusts the intelligence agencies, because he doesn't want to hear about Russian interference in his election, it is just as bad.
whatevertrevor 7y ago
Not OP, but because it often slows down development since different teams keep re-implementing similar ideas or have strong requirements to allow using their infrastructure. There are always trade-offs to consider, silo-ing projects can be critical to some core infrastructure projects and security libraries, can be very useful for other control plane projects, but can also actively hinder innovation in other cases. That's a wordy way of saying it's not always the most efficient use of resources.
gumby 7y ago
TO be clear I consider Apples level of inter-group secrecy insane. When Apple switched from PPC to Intel I had friends who worked on apple's dev tools (like gdb) who learned about the switch the same day I did. That's over the top. Apple doesn't have divisions; it would be unremarkable that GE's jet engine business didn't know what GE's medical MRI division was up too. But Apple has a small number of products that essentially share a backbone. Yet features are poorly integrated; Mac photos is ahead if iOS's in some ways and behind in others suggesting less shared code than would be more efficient, less buggy, and less confusing the users. The Mac has a whole en ("ink") infrastructure which is more powerful than what's on the iPod despite the iPod having much more common pen support. And let's not get to security architecture... At the other extreme Google has (mostly) a monorepo. They have their own problems but act to improve connection between the company. Cisco used to and probably still does have a number of common architectural structures across its product line. Etc.
- hrktb 7y ago
  It feels weird having Google on the “improve connection between the company” side when they are the poster child of parallel implementations and internal competing products and standards (at least as seen from the outside). It is just a warped perception ?
  - gumby 7y ago
    I don't think so. I just cited their monorepo as an approach close to opposite polar extreme. In reality they don't actually have a single, company-wide repo, and they also have some groups that have isolation almost as extreme as Apple's. Any large company will have these communication problems I cited; the part I find weird is that Apple not only takes no steps to address them but takes steps that as side effects exacerbate the issue. Clearly it doesn't bother them and they do ship good products so...
- jiveturkey 7y ago
  > At the other extreme Google has (mostly) a monorepo. One shouldn't conflate the VCS with org structure and/or code sharing. The Google monorepo is perforce-based, which has per-branch, per-directory (even per-file) access control. One project's dependency on another can just as easily use the build artifacts from that other project as it can a source tree. And the way Google has built it, is looks far far closer to git than what you might think of with p4 (or svn or vss or name-your-monorepo). Lastly, AIUI, from day one there were very restricted parts of the "monorepo" that only a very few devs had access to. The Google monorepo is very different than a single git repo.

Just curious, why do you think that inter-project secrecy within a company is a bad idea?

markdown 7y ago

For the same reason that inter-agency secrecy contributed to the success (for the terrorists) of the 9/11 attacks.

lostgame 7y ago
You mean the departments of government that planned and staged 9/11 didn’t communicate with the departments that would have to believe the cover story? I mean, that makes sense, why would they? I mean, why would a government stage an attack against its own people, anyways? Oh, right. Oil and war profits.
- enraged_camel 7y ago
  >>You mean the departments of government that planned and staged 9/11 Holy molly. We're spouting insane conspiracy theories on this site, now?
  - miopa 7y ago
    9/11 was a conspiracy. But because the official theory about it is very shaky, alternative theories (some insane, some not so much) are bound to sprout.
  - IOT_Apprentice 7y ago
    No, it is simpler. US intelligence agencies pre-911 did not share intelligence or pass along warnings across agency boundaries. That meant events such as the terrorists that went to flight school in Florida, did not get passed along to other agencies. It is why post-911 there is a DNI. However, when you have a chaos president, who distrusts the intelligence agencies, because he doesn't want to hear about Russian interference in his election, it is just as bad.

whatevertrevor 7y ago

Not OP, but because it often slows down development since different teams keep re-implementing similar ideas or have strong requirements to allow using their infrastructure. There are always trade-offs to consider, silo-ing projects can be critical to some core infrastructure projects and security libraries, can be very useful for other control plane projects, but can also actively hinder innovation in other cases. That's a wordy way of saying it's not always the most efficient use of resources.

gumby 7y ago

TO be clear I consider Apples level of inter-group secrecy insane. When Apple switched from PPC to Intel I had friends who worked on apple's dev tools (like gdb) who learned about the switch the same day I did. That's over the top. Apple doesn't have divisions; it would be unremarkable that GE's jet engine business didn't know what GE's medical MRI division was up too. But Apple has a small number of products that essentially share a backbone. Yet features are poorly integrated; Mac photos is ahead if iOS's in some ways and behind in others suggesting less shared code than would be more efficient, less buggy, and less confusing the users. The Mac has a whole en ("ink") infrastructure which is more powerful than what's on the iPod despite the iPod having much more common pen support. And let's not get to security architecture... At the other extreme Google has (mostly) a monorepo. They have their own problems but act to improve connection between the company. Cisco used to and probably still does have a number of common architectural structures across its product line. Etc.

hrktb 7y ago
It feels weird having Google on the “improve connection between the company” side when they are the poster child of parallel implementations and internal competing products and standards (at least as seen from the outside). It is just a warped perception ?
- gumby 7y ago
  I don't think so. I just cited their monorepo as an approach close to opposite polar extreme. In reality they don't actually have a single, company-wide repo, and they also have some groups that have isolation almost as extreme as Apple's. Any large company will have these communication problems I cited; the part I find weird is that Apple not only takes no steps to address them but takes steps that as side effects exacerbate the issue. Clearly it doesn't bother them and they do ship good products so...
jiveturkey 7y ago
> At the other extreme Google has (mostly) a monorepo. One shouldn't conflate the VCS with org structure and/or code sharing. The Google monorepo is perforce-based, which has per-branch, per-directory (even per-file) access control. One project's dependency on another can just as easily use the build artifacts from that other project as it can a source tree. And the way Google has built it, is looks far far closer to git than what you might think of with p4 (or svn or vss or name-your-monorepo). Lastly, AIUI, from day one there were very restricted parts of the "monorepo" that only a very few devs had access to. The Google monorepo is very different than a single git repo.