People seem to vastly underestimate the (accidental) complexity introduced by branching and delaying integration, and overestimate the risk of integrating and r

People seem to vastly underestimate the (accidental) complexity introduced by branching and delaying integration, and overestimate the risk of integrating and releasing the changes, which is literally the essence of professional software development. Your job from the business perspective is getting the changes into production. Facilitating that makes high-performing teams. Think about what you would need in order to safely merge to main multiple times a day. Trustworthy test suite? "Extra pair of eyes but without the wait and comment ping-pong", also known as "pair programming"? Build automation? Great deployment scripts? Trusted feature toggles? Shared code ownership? Doing "feature branching" instead of that you get exotic branching strategies, sophisticated infrastructure to deploy your system from any desired branch, PRs hanging for weeks, even months, testing features in isolation, required approval rules, big merge conflicts... and a dumpster fire when something inevitably breaks and it turns out eventually you HAVE TO merge that hotfix to main branch QUICKLY. I've worked in teams that mandate double code review, for reasons of "safety and code quality". Guess what. Code quality was shit anyway, and deployments were done infrequently, always with the feeling that it's risky. I've helped same teams to simplify the workflow and deliver more value by just building the trust and gradually transitioning from "ask" to "show" & "ship" approach. I like the article a lot, since it describes something I've seen to emerge in reality. But don't take my word on it, watch this instead: https://www.youtube.com/watch?v=v4Ijkq6Myfc https://www.youtube.com/watch?v=v4Ijkq6Myfc