Comments by "Brent Jacobs" (@br3nto) on "Why The Hell Do You Still BRANCH?!" video.

  1. I’m actually really concerned about the messaging in this vid and others like it. It’s a disservice to our community. People shouldn’t be taught fanatically that one thing is good and another thing is bad. They should instead be taught the trade-offs, and taught the skills to be able to make informed choices. Branches are good for the things I mentioned in another comment, but there is a trade-off to be made the longer a branch is left open and the more code that goes into it. By jumping to “branches are bad”, you’re skipping important teaching points like how to break large problems down into smaller problems, and how to introduce fundamentally different code without breaking everything. For example a fundamental breaking change from a one-one relationship to a has-many relationship in your DB when a lot of app logic is implemented as role-based logic, and now needs to shift to resource-based logic. It takes a different kind of skill to do that in a CI way. You’re missing the opportunity to talk about that and teach those skills. Please stop being so fanatical about “branches are bad”, and instead focus on the skills devs need to be able to push changes to production faster.
    50
  2.  @michaelrstover  I’m quite well watched. If Dave won’t provide balance, I will. I hope others do too.
    13
  3. It’s literally impossible to not do branch based development. When you check out a branch from a remote repo, a new branch is created. It’s actually awesome that we can do that. We should create branches. How often are you in the middle of making a change when a new more urgent requirement comes up? Either stash or commit your change in a branch, then create a new branch for the new work. You can’t do that if you don’t use branches. They let you be creative. They let you try new things without effecting the main branch. It’s perfect for the creative process. It is the worst advice to not use branches. Don’t listen to it. Stale and long-lived branches on the other hand are the devil. If you have a branch, you need to frequently rebase it, but the more code in that branch it’ll start holding up other dev work that is planning to rely on that work. This forces work to be done in serial instead of parallel, and that really slows a team down.
    9
  4. From my perspective, this happens because the people managing software teams and projects have absolutely no formal or informal training in software engineering. What exacerbates this, is there is an IT department and CTO and/or CIO, but no software department and CSEO to discuss, encourage, and assist with good consistent practices. Only people with software engineering training/experience should manage software engineering/development teams, and there should probably be a corresponding department and representation at board level. Not only this, but software engineers are the only profession that could also extend their training to refactoring company structures to make them more efficient, and solve all the silo issues. (Assuming that company processes and hierarchies are same enough to the patterns seen in software).
    3
  5. 💯. The things you mentioned are 100% the first things a dev team needs to do to achieve CI. Fix deployment pain, increase observability and testability. CI isn’t just something a team can achieve overnight. There are steps that must be taken to make it happen. Dogmatically saying CI is the only way and branches are bad skips over all the important discussions and learning that a dev team needs to take on board to make CI happen and also skips teaching about all the nuances and tradeoffs that can legitimately be made along the way.
    2
  6. You can easily do CI and use branches together. Branches are a creativity and productivity tool that can be effectively used to do CI. The thing being glossed over is all the skills that a dev needs to develop in order to do CI. How to break problems down into smaller pieces without breaking the app is not something taught well. It requires a different type of thinking and methodology than simply writing an entire feature or change in a branch and then merging it. It’s a shame that this conversation skips talking about those needed skills to make CI work.
    2
  7. Switching priorities causes you to need to temporarily work on another feature. You want to run an experiment or two or three to compare different approaches to the same problem. Branching can be a great creativity and productivity tool. I don’t agree with b or c. I think b is problematic because there’s a good chance a patch will need to be applied to both versions, but now you need to apply the same code twice (or more, depending on how many versions you’re managing). It would be better if both versions were supported in the main branch. I think c is probably because data scientists and others have less formal software engineering training. There is less incentive and/or knowledge to write maintainable and shareable software. Even throwaway code can be useful in the future, so merging it into the main branch and making it shareable and maintainable would be more beneficial in the long run. That just an assumption, but backed by some first hand experience.
    2
  8. Dave is unfortunately skipping over all the steps required to make a codebase Continuously Integratable. Any codebase could be transformed to use CI. Some are just written so poorly that a lot of work is required to make it happen. That time and effort would probably be worth if it takes up to a month to validate a change. How can a company keep their competitive advantage when their codebases move that slow?
    1