3 ms·

Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many develop

by nvarsj 11y ago

Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict. Ugh, such a false dichotomy. Does anyone actually think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is a good idea? Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models. Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.

nilliams 11y ago
I don't quite understand your comment, are you saying you are for-or-against feature branches? Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching? Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches. However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge). [0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-practices-for-software-projects-with-neal-ford https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-oh-my/ http://theshipshow.com/2013/09/branching-merging-and-octopi-...
madeofpalk 11y ago
It's about long-lived branch-based development which defers feedback. That's what's dangerous. I don't think OP is claiming that all branches are evil.
davidrupp 11y ago
"[P]aired programming is about optimizing for the team" (source: http://goodrequirements.com/2013/pair-programming/ http://goodrequirements.com/2013/pair-programming/). Long-lived feature branches optimize for the individual. A useful alternative is described at http://paulhammant.com/blog/branch_by_abstraction.html http://paulhammant.com/blog/branch_by_abstraction.html. What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.

by nvarsj 11y ago

nilliams 11y ago

I don't quite understand your comment, are you saying you are for-or-against feature branches? Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching? Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches. However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge). [0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-practices-for-software-projects-with-neal-ford https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-oh-my/ http://theshipshow.com/2013/09/branching-merging-and-octopi-...

madeofpalk 11y ago

It's about long-lived branch-based development which defers feedback. That's what's dangerous. I don't think OP is claiming that all branches are evil.

davidrupp 11y ago

"[P]aired programming is about optimizing for the team" (source: http://goodrequirements.com/2013/pair-programming/ http://goodrequirements.com/2013/pair-programming/). Long-lived feature branches optimize for the individual. A useful alternative is described at http://paulhammant.com/blog/branch_by_abstraction.html http://paulhammant.com/blog/branch_by_abstraction.html. What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.