4 ms·

> Ultimately, it turned out to be one of our dependencies turning on a feature by slowly increasing the probability it was used. Wow. I feel like this dependen

> Ultimately, it turned out to be one of our dependencies turning on a feature by slowly increasing the probability it was used. Wow. I feel like this dependency should be named and shamed.

Laremere 3y ago
Big company internal dependency. So nothing for the public to care about.
- vamega 3y ago
  What company. I've seen this being done (and my team does it a lot at Amazon) but curious to know if others are doing it at build time too. If done in a company with a monorepo I'd be especially interested in hearing more
  - aeyes 3y ago
    > If done in a company with a monorepo I'd be especially interested in hearing more Are there any big companies left which haven't adopted a monorepo?
    - deleted 3y ago
      [deleted]
    - PartiallyTyped 3y ago
      AWS. We probably have the worst build systems :(
      - scubbo 3y ago
        This is astonishing. The build (and deploy) systems are, by a considerable margin, the things I miss most about having left Amazon (CDO, not AWS, but still). What do you dislike about them?
        phinnaeus 3y ago
        I'm in a similar boat. I worked in both CDO and AWS. I miss Brazil and Isengard every day
        PartiallyTyped 3y ago
        I do concede that isengard is pretty cool. I am looking forward to Peru as it will make dealing with dependencies a lot easier.
        PartiallyTyped 3y ago
        I had to spend days trying to debug why a build that was working fine broke completely and NPMPM was unable to find the dependencies for the lambda. I disliked how needlessly convoluted the pipelines are, and how some person pushing on accident to mainline can break everything. So many things seem to be done the hard way.
        scubbo 3y ago
        > I had to spend days trying to debug why a build that was working fine broke completely Sure, but I bet that it was helpful to have the `bats` tool so that you could replicate the build locally, right? As compared with other build systems where (so far as I can see - though I may be wrong) you basically have to push a debugging change for replication. > I disliked how needlessly convoluted the pipelines are, and how some person pushing on accident to mainline can break everything. This is true of any CI/CD system, though? In any system, if there's no push-protection set up so that you can only merge into main(/line) once a change has been reviewed (and run your tests at the point of review so that you know the merge won't break anything), you have only yourself to blame for breakage. > So many things seem to be done the hard way. Genuine question - what do you find convoluted/hard about them? To me, the apparently-industry-standard of "push a change to your App Code, which triggers a build to generate a docker image, then trigger an automatic commit containing that Docker image to a Deployment Package, which is picked up by your CD system and creates a deployment" is way more convoluted. Having a conceptual "pipeline" built out of lots of little disconnected GitHub Actions (or whatever) is also way harder for me to wrap my head around than the CDK definition of a linear pipeline.
    - de-moray 3y ago
      Microsoft has not implemented a monorepo. However, it's not surprising when you consider the massive breadth of software that Microsoft builds, as one of the oldest and largest software development orgs.
    - hedora 3y ago
      Monorepos solve a very specific set of problems that ~ 0% of companies have. I doubt single digit percentages of, say, the fortune 500 use them, and I'd be surprised if double digit percentages of companies use them at IPO.
      - necovek 3y ago
        Well, they do solve a bunch of problems every company has, but introduce another set of problems those companies didn't have until that point. As with anything, striking the balance and finding when to use a tool is the hardest question.
    - scubbo 3y ago
      Amazon (or, at least, my corner of it) still hadn't when I left ~9 months ago - and I'm glad of it. I've moved to a company where one of the core products (though, thankfully, not my team's) is in a monorepo, and from everything I've seen it looks like a horribly inefficient way to develop.
    - raverbashing 3y ago
      Why should companies jump on the latest fad and join things that don't belong in the same repo?
thehappypm 3y ago
Isn’t this how multi-armed bandits work?
- rootsudo 3y ago
  algo 101, but I can see how it can be nifty for $internalapp.

> Ultimately, it turned out to be one of our dependencies turning on a feature by slowly increasing the probability it was used. Wow. I feel like this dependency should be named and shamed.

Laremere 3y ago

Big company internal dependency. So nothing for the public to care about.

vamega 3y ago
What company. I've seen this being done (and my team does it a lot at Amazon) but curious to know if others are doing it at build time too. If done in a company with a monorepo I'd be especially interested in hearing more
- aeyes 3y ago
  > If done in a company with a monorepo I'd be especially interested in hearing more Are there any big companies left which haven't adopted a monorepo?
  - deleted 3y ago
    [deleted]
  - PartiallyTyped 3y ago
    AWS. We probably have the worst build systems :(
    - scubbo 3y ago
      This is astonishing. The build (and deploy) systems are, by a considerable margin, the things I miss most about having left Amazon (CDO, not AWS, but still). What do you dislike about them?
      - phinnaeus 3y ago
        I'm in a similar boat. I worked in both CDO and AWS. I miss Brazil and Isengard every day
        PartiallyTyped 3y ago
        I do concede that isengard is pretty cool. I am looking forward to Peru as it will make dealing with dependencies a lot easier.
      - PartiallyTyped 3y ago
        I had to spend days trying to debug why a build that was working fine broke completely and NPMPM was unable to find the dependencies for the lambda. I disliked how needlessly convoluted the pipelines are, and how some person pushing on accident to mainline can break everything. So many things seem to be done the hard way.
        scubbo 3y ago
        > I had to spend days trying to debug why a build that was working fine broke completely Sure, but I bet that it was helpful to have the `bats` tool so that you could replicate the build locally, right? As compared with other build systems where (so far as I can see - though I may be wrong) you basically have to push a debugging change for replication. > I disliked how needlessly convoluted the pipelines are, and how some person pushing on accident to mainline can break everything. This is true of any CI/CD system, though? In any system, if there's no push-protection set up so that you can only merge into main(/line) once a change has been reviewed (and run your tests at the point of review so that you know the merge won't break anything), you have only yourself to blame for breakage. > So many things seem to be done the hard way. Genuine question - what do you find convoluted/hard about them? To me, the apparently-industry-standard of "push a change to your App Code, which triggers a build to generate a docker image, then trigger an automatic commit containing that Docker image to a Deployment Package, which is picked up by your CD system and creates a deployment" is way more convoluted. Having a conceptual "pipeline" built out of lots of little disconnected GitHub Actions (or whatever) is also way harder for me to wrap my head around than the CDK definition of a linear pipeline.
  - de-moray 3y ago
    Microsoft has not implemented a monorepo. However, it's not surprising when you consider the massive breadth of software that Microsoft builds, as one of the oldest and largest software development orgs.
  - hedora 3y ago
    Monorepos solve a very specific set of problems that ~ 0% of companies have. I doubt single digit percentages of, say, the fortune 500 use them, and I'd be surprised if double digit percentages of companies use them at IPO.
    - necovek 3y ago
      Well, they do solve a bunch of problems every company has, but introduce another set of problems those companies didn't have until that point. As with anything, striking the balance and finding when to use a tool is the hardest question.
  - scubbo 3y ago
    Amazon (or, at least, my corner of it) still hadn't when I left ~9 months ago - and I'm glad of it. I've moved to a company where one of the core products (though, thankfully, not my team's) is in a monorepo, and from everything I've seen it looks like a horribly inefficient way to develop.
  - raverbashing 3y ago
    Why should companies jump on the latest fad and join things that don't belong in the same repo?

thehappypm 3y ago

Isn’t this how multi-armed bandits work?

rootsudo 3y ago
algo 101, but I can see how it can be nifty for $internalapp.