These are largely subjective choices that have no positive nor negative bearing on how fast you ship. > Avoid Feature Branches > Break features into small, in

These are largely subjective choices that have no positive nor negative bearing on how fast you ship. > Avoid Feature Branches > Break features into small, incremental changes This makes efficient & organised writing of code easier but makes product development harder or at least very artificially limited. If you want to ship fast this will help. If you want to ship quality & value, this will likely hamper you. This needs to be compromise - feature branches can be tricky to manage well, but it's better to learn how to than avoid it. It will allow you to manage complexity and meet your target audience's needs more effectively. > Use a monorepo Absolutely arbitrary and has zero bearing on speed of delivery. Monorepos vs monoliths vs multi-repo microarch is as efficient / in-efficient as your choice of app architecture, team structure, tooling, software ecosystem, etc. It depends on far too many variables to be a blanket positive. > Automate CI/CD pipeline > will make it easy to release changes multiple times a day > Deploy weekly There's a lot of contradictions here. Deploy/release much more often than weekly. Please. > Freeze the code before release [...] This is not to improve the speed OK. > Write tests (or not?) Make up your mind. > Request at least one demo per week This is generally reasonable advice, but the cadence seems too frequent. Demos are expensive w.r.t. developer's time & energy - they should be frequent but still leave some time for actual dev in between. > Use feature flags This is nice if it's simple (if you're following the "Break features into small, incremental changes" advice I guess you have no large/complex features). If you do have any large features, feature flags can sometimes come with side-effects, impacting performance / stability / security of your overall application. Follow this with care. > Define owners This sounds like good advice until you read the author's description: > avoid the shared responsibility trap, when no one is responsible This sounds like a bad manager or dysfunctional company - shared responsibility is a good thing actually. If your engineers aren't motivated to own code, that's a different problem. > The feature owner knows explicitly that no one else is going to complete their work. This sounds like a very dysfunctional team. If you have this problem, work on your culture, don't try and fix it with technical solutions. Overall, code ownership is good as long as it's shared. Bus factor is a thing. --- This all seems like the common mistake of mis-attributing success to a large but irrelevant change that coincides with many small beneficial incremental learnings. Imagined example of the above: say the author moved from a disorganised mess of many disparate repos to a fresh-start carefully-planned monorepo: things didn't improve because it's a monorepo, things improved because someone sat down and planned out the organisation of code to fit their needs (needs which probably evolved to that point of maturity over many small repo-structure changes before). Correct connclusion here isn't "monorepos are good", it's "sitting down and re-thinking/re-organising/planning code structure periodically is good".