Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How big tech runs tech projects and the curious absence of Scrum

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

51–60 of 452 posts

Re: How big tech runs tech projects and the curious absence of Scrum

#51

Post by UK-Al05 »

deepGem wrote: post #38
sparsely wrote: post #15

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you wor…

That's branching. Trunk is when everyone direct push access to trunk.

Re: How big tech runs tech projects and the curious absence of Scrum

#52

Post by sparsely »

stepanhruda wrote: post #35
sparsely wrote: post #15

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

The latter

The replies seem to suggest that there are a mix of interpretations, it's very confusing.

Re: How big tech runs tech projects and the curious absence of Scrum

#53

Post by Traster »

deepGem wrote: post #38
sparsely wrote: post #15

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

I worked on a Tensorflow feature in 2018. There was no branching involved. Fork the main repo, build the feature on your child repo, make sure all unit tests pass and then send a pull request to the main/master of the parent repo. Typically someone reviews the code, you incorporate code review comments, pass all unit tests, CI-CD pass, PR approved. That's it. Your code is in the next production cycle. So yes, you wor…

How would you describe the difference between branches and forks? Functionally I can create a new branch, do my changes, get tests passing and PR from there, or I can fork master, do my changes, get tests passing and PR.

Re: How big tech runs tech projects and the curious absence of Scrum

#54

Post by lbriner »

root-z wrote: post #44

I worked at a big tech for many years and my team never managed to get Scrum working properly. Every year my team commits a delivering certain product/features at a very specific date (some sort of launch event), so we have to know very early in the year what's all the work required and report periodically whether project is on track. The deadlines are also always on the tighter end. The flexibility of Scrum becomes…

You cannot get management buy-in to Scrum or most agile processes unless they can accept the agile manifesto principles.

The whole idea that you can be agile while having delivery dates for things several months in advance is a nonsense. Agile is about doing what is important now, not doing what we thought was important a few months ago.

The best you could probably hope for is Kanban or the never-ending backlog but some people struggle when there is no finish line, just an endless sea of work!

Re: How big tech runs tech projects and the curious absence of Scrum

#55

Post by sparsely »

whynotmaybe wrote: post #33
sparsely wrote: post #15

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

Maybe have a look at this https://trunkbaseddevelopment.com/

This seems to be advocating the second workflow, i.e. pushing on a short lived branch then merging back in (their intermediate setup seems impractical technically for most setups - how do you run standard tests without committing your code, unless you do everything locally?)

Re: How big tech runs tech projects and the curious absence of Scrum

#57

Post by deepGem »

So the key takeaway here is that the Plan, build(iterate), ship cycle works very well. Most successful teams stick to this. What is not clear to me is how an abrupt new feature with an urgent deadline fits into all this ? "We'll fit this into the next release cycle" is not an option, let's say.

So how do you fit in this new requirement ? You are already in the middle of a feature built on day 3 or 4. Devs are working on their forks and have uncommitted code. Now you have a new feature that has to be given priority, assuming there are no dependencies on the existing cycle. Do you just keep a copy of your old work, and start working on this new stuff ? Feels like a mess. Any better approaches ?

Re: How big tech runs tech projects and the curious absence of Scrum

#58

Post by sparsely »

science4sail wrote: post #28
sparsely wrote: post #15

> Many teams work on main branches, get quick feedback from CI/CD systems and can immediately share functionality which they are working on with other team members. I occasionally see statements like this floating around - does he mean: * Devs make their changes locally, commit and push directly to main, and then the CI/CD either notifies them that tests failed or deploys to prod or * Devs make their changes locally,…

> The first seems like it would be very frustrating if code with failing tests if pushed with any frequency, but seems to be literally what the phase "work on main" means. Yep, that's the point - it's to discourage devs from checking in failing code (because then they'll be swarmed by annoyed coworkers). It's fairly common to see developer A make a breaking change to some low-level library and then see developer B pu…

If that's fairly common it doesn't seem like a great setup? Why not automatically run the tests beforehand?

And presumably there is no need for a staging env, since your code is deployed to production as soon as it has passed tests.

Re: How big tech runs tech projects and the curious absence of Scrum

#60

Post by [deleted] »

hatchnyc wrote: post #22

> Engineers are encouraged to interact with the rest of the business and build relationships with non-engineers. In contrast, traditional companies often make it impossible for developers to interact with the rest of the business. In my experience “traditional companies” will often have a bunch of people in cushy “gatekeeping“ jobs whose main function is basically forwarding emails back and forth between devs and the…

[deleted]
Post reply on HN