We are often asked if our teams use feature branches and/or pull requests in our projects. When we say no, the next question is usually followed by some form of “don’t you guys care about quality?”.
We do very much; quality is one of our primary concerns. We used pull requests and feature branches in the past, but found that in most cases, contrary to intuition, they lead to decreases in quality, not increases. PRs are a great tool to manage your codebase, however they introduce some horrible traps that many development teams tend to fall into - especially with commercial projects.
Here are some of the pitfalls when branching a project:
You can recognize if your team has fallen into one of these traps when your team members often ask if something is already merged (a very bad sign).
Result: a week of developers’ work has to be re-done. The PM is sad, the client is sad.
Result: time loss and quality plummeting, nothing to be done at this point beside refactoring, which probably won’t be welcomed as implementation already took double the amount of time than it should have. Developers are sad, PM is sad, client is sad, and kittens are very sad.
DEVELOPER: I’m going to start the SuperCrm integration ticket now! It’s just another Integration. Easy peasy - 2 days tops.
OTHER DEV: Can you wait a bit? I’m rewriting Integration now, it’s going to be super easy peasy to do your story once I’m done.
[2 days later]
DEVELOPER: I’m going to start SuperCrm ticket now!
OTHER DEV: Can you wait a bit? I’m still not done.
CLIENT: So it’s 4 days total now?
PROJECT MANAGER: :/
[Other dev quit, lost connection]
All those traps lead to time and work loss, and in turn, to quality decreases. But there is one more story that is the worst one here. This is the story of lost value.
NEW DEVELOPER: Is that branch important?
DEVELOPER: No it’s just my 2 week refactoring I did last year but never finished because I had to take care for that other thing...
‘Never finished / never merged’ branches and features in the repo are the manifestation how much value is lost in the process - as clear as it gets.
Branch as sad as sad kitty (from a project we took over recently)
That's all for now. In the second part of this post you will find what our team does instead of branching - and how we keep our developers, clients and kittens happy.