Topics

Gently nudging a team away from feature branches/pull requests and towards continuous integration


J. B. Rainsberger
 

Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 


George Dinwiddie
 

I question the use of the word "team" if no one can be bothered to review a pull request for 10+ days. I would start with building a sense of teamness. Solo programmers is just a symptom of a work group that is not teaming.

- George

On 2/17/20 1:11 PM, J. B. Rainsberger wrote:
Here is a Twitter exchange I had a while ago:
https://twitter.com/svarlet/status/1191375183141101568
When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."
I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done.
What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation.
J. B. Rainsberger :: https://tdd.training | https://jbrains.ca | https://blog.thecodewhisperer.com
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach
----------------------------------------------------------------------


J. B. Rainsberger
 

Indeed, I like to use the words "group" and "team" more precisely and I'd use the word "group" here. 

I spent some time two years ago with a group who asked me about delays in reviewing their pull requests, and I recall the central issue lay in a lack of self-confidence, resulting in not wanting to criticize someone else's work. This _seemed_ to have less to do with fearing reprisal and more to do with genuine lack of confidence in their own judgment. "Who am I to criticize their code?" 

This morphed into a 90-minute discussion about how they treat each other and some other fundamental awareness of trust issues within the group. They tried some trust-building exercises revolving around criticizing code together and they reported some improvement. I don't know about any lasting change, however.


On Mon., Feb. 17, 2020, 13:37 George Dinwiddie, <lists@...> wrote:
I question the use of the word "team" if no one can be bothered to
review a pull request for 10+ days. I would start with building a sense
of teamness. Solo programmers is just a symptom of a work group that is
not teaming.

  - George

On 2/17/20 1:11 PM, J. B. Rainsberger wrote:
> Here is a Twitter exchange I had a while ago:
>
> https://twitter.com/svarlet/status/1191375183141101568
>
> When I asked what problems the group in question were experiencing,
> Sébastien answered, "Individuals working solo for 10+ days on something,
> then open a PR which remains open for 10+ days because rest of the team
> is not available or because it’s too big to review quickly. I did
> explain factually and ran a pair programming experiment. While the
> benefits of the experiment were observed collectively, everyone defended
> that some work remains better done in solo (online search, docs, ...).
> This is acceptable and likely true yet was an excuse to start, and
> finish, anything in solo."
>
> I suggested applying the principle of cutting a long feedback cycle in
> half, to see what would change and what the group would learn. One
> person wondered whether group members were hiding their ignorance (about
> something, anything) in their resistance to complete smaller tasks.
> Sébastien worries that the question of "smaller batches of work" would
> open a bigger can of worms, which, to be frank, it would and perhaps
> needs to be done.
>
> What would you suggest or want to ask Sébastien? Maybe we can get him
> here to join the conversation.
>
> J. B. Rainsberger :: https://tdd.training | https://jbrains.ca |
> https://blog.thecodewhisperer.com
>

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach
  ----------------------------------------------------------------------





Charlie Poole
 

If people are pairing, I'm wondering what value you get out of pull
requests anyway. I think in that case, I'd try to move the team away
from PRs entirely.

Even if they are not pairing, my current thinking is that PR approval
should be at the option of the team member. I'm assuming that nothing
gets into the master unless all tests pass and that we start out with
a well-tested application. If not, I'd say those are prerequisites,
but it's hard to see how gateways increase a sense of personal
responsibility on the part of the team members. We already hold
developers responsible for good coding and testing practice. Why not
hold them responsible for knowing when a review of their work is
needed?

Unfortunately, since I'm retired, someone else will have to try this
out on a live team. :-( I have done it a bit on my open source work
and I continue to like it.

Charlie

On Mon, Feb 17, 2020 at 10:46 AM J. B. Rainsberger <jbrains762@gmail.com> wrote:

Indeed, I like to use the words "group" and "team" more precisely and I'd use the word "group" here.

I spent some time two years ago with a group who asked me about delays in reviewing their pull requests, and I recall the central issue lay in a lack of self-confidence, resulting in not wanting to criticize someone else's work. This _seemed_ to have less to do with fearing reprisal and more to do with genuine lack of confidence in their own judgment. "Who am I to criticize their code?"

This morphed into a 90-minute discussion about how they treat each other and some other fundamental awareness of trust issues within the group. They tried some trust-building exercises revolving around criticizing code together and they reported some improvement. I don't know about any lasting change, however.

J. B. Rainsberger :: https://tdd.training | https://jbrains.ca | https://blog.thecodewhisperer.com

On Mon., Feb. 17, 2020, 13:37 George Dinwiddie, <lists@idiacomputing.com> wrote:

I question the use of the word "team" if no one can be bothered to
review a pull request for 10+ days. I would start with building a sense
of teamness. Solo programmers is just a symptom of a work group that is
not teaming.

- George

On 2/17/20 1:11 PM, J. B. Rainsberger wrote:
Here is a Twitter exchange I had a while ago:

https://twitter.com/svarlet/status/1191375183141101568

When I asked what problems the group in question were experiencing,
Sébastien answered, "Individuals working solo for 10+ days on something,
then open a PR which remains open for 10+ days because rest of the team
is not available or because it’s too big to review quickly. I did
explain factually and ran a pair programming experiment. While the
benefits of the experiment were observed collectively, everyone defended
that some work remains better done in solo (online search, docs, ...).
This is acceptable and likely true yet was an excuse to start, and
finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in
half, to see what would change and what the group would learn. One
person wondered whether group members were hiding their ignorance (about
something, anything) in their resistance to complete smaller tasks.
Sébastien worries that the question of "smaller batches of work" would
open a bigger can of worms, which, to be frank, it would and perhaps
needs to be done.

What would you suggest or want to ask Sébastien? Maybe we can get him
here to join the conversation.

J. B. Rainsberger :: https://tdd.training | https://jbrains.ca |
https://blog.thecodewhisperer.com
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach
----------------------------------------------------------------------




russgold
 

One problem I see is that most developers are not so aware. TDD seems still very much the exception rather than the rule. It doesn’t seem to be taught in most university Computer Science programs, which is one of two main ways that most programmers learn to program (the other being self-study). It is a technique that you need when you are building a non-trivial system, but training tends to be on very small programs, entirely written by students for each course. That allows the more obvious technique of “keeping everything in your head,” which doesn’t scale up well.

On Feb 17, 2020, at 2:54 PM, Charlie Poole <charliepoole@...> wrote:

If people are pairing, I'm wondering what value you get out of pull
requests anyway. I think in that case, I'd try to move the team away
from PRs entirely.

Even if they are not pairing, my current thinking is that PR approval
should be at the option of the team member. I'm assuming that nothing
gets into the master unless all tests pass and that we start out with
a well-tested application. If not, I'd say those are prerequisites,
but it's hard to see how gateways increase a sense of personal
responsibility on the part of the team members. We already hold
developers responsible for good coding and testing practice. Why not
hold them responsible for knowing when a review of their work is
needed?

Unfortunately, since I'm retired, someone else will have to try this
out on a live team. :-( I have done it a bit on my open source work
and I continue to like it.

Charlie

On Mon, Feb 17, 2020 at 10:46 AM J. B. Rainsberger <jbrains762@...> wrote:

Indeed, I like to use the words "group" and "team" more precisely and I'd use the word "group" here.

I spent some time two years ago with a group who asked me about delays in reviewing their pull requests, and I recall the central issue lay in a lack of self-confidence, resulting in not wanting to criticize someone else's work. This _seemed_ to have less to do with fearing reprisal and more to do with genuine lack of confidence in their own judgment. "Who am I to criticize their code?"

This morphed into a 90-minute discussion about how they treat each other and some other fundamental awareness of trust issues within the group. They tried some trust-building exercises revolving around criticizing code together and they reported some improvement. I don't know about any lasting change, however.

J. B. Rainsberger :: https://tdd.training | https://jbrains.ca | https://blog.thecodewhisperer.com

On Mon., Feb. 17, 2020, 13:37 George Dinwiddie, <lists@...> wrote:

I question the use of the word "team" if no one can be bothered to
review a pull request for 10+ days. I would start with building a sense
of teamness. Solo programmers is just a symptom of a work group that is
not teaming.

 - George

On 2/17/20 1:11 PM, J. B. Rainsberger wrote:
Here is a Twitter exchange I had a while ago:

https://twitter.com/svarlet/status/1191375183141101568

When I asked what problems the group in question were experiencing,
Sébastien answered, "Individuals working solo for 10+ days on something,
then open a PR which remains open for 10+ days because rest of the team
is not available or because it’s too big to review quickly. I did
explain factually and ran a pair programming experiment. While the
benefits of the experiment were observed collectively, everyone defended
that some work remains better done in solo (online search, docs, ...).
This is acceptable and likely true yet was an excuse to start, and
finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in
half, to see what would change and what the group would learn. One
person wondered whether group members were hiding their ignorance (about
something, anything) in their resistance to complete smaller tasks.
Sébastien worries that the question of "smaller batches of work" would
open a bigger can of worms, which, to be frank, it would and perhaps
needs to be done.

What would you suggest or want to ask Sébastien? Maybe we can get him
here to join the conversation.

J. B. Rainsberger :: https://tdd.training | https://jbrains.ca |
https://blog.thecodewhisperer.com


--
 ----------------------------------------------------------------------
  * George Dinwiddie *                      http://blog.gdinwiddie.com
  Software Development                    http://www.idiacomputing.com
  Consultant and Coach
 ----------------------------------------------------------------------








David Bogus
 

I would ask a few questions to understand the structer of the group. 

"Is there a single source of funding for all changes to the shared code base?"

If there are multiple sources of funding I would follow up with "Can any team members charge against any source without pre approval?"






On Mon, Feb 17, 2020, 1:11 PM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 


russgold
 

And if there is a single source of funding, what would you do with that information?

On Feb 17, 2020, at 4:33 PM, David Bogus <DavidBogus@...> wrote:

I would ask a few questions to understand the structer of the group. 

"Is there a single source of funding for all changes to the shared code base?"

If there are multiple sources of funding I would follow up with "Can any team members charge against any source without pre approval?"






On Mon, Feb 17, 2020, 1:11 PM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 




Phil Goodwin
 

Maybe those folks should start having retrospectives. It helps to get them to feed each other (with e.g. rotating snack duties), but pretty much anything you can do to get them to take care of each other will help -- team lunches, birthday parties, etc. If they are used to taking care of each other away from the code it will feel natural to take care of each other within the code. It's gotta feel ok to make mistakes, both in coding and reviewing. I used to think agility was about feedback. It's not. It's about trust, and that has to be earned. Once it's there, and there's a venue for making improvements, the team will be able to start experimenting with solutions rather than defending self images.


On Mon, Feb 17, 2020, 10:11 AM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 


David Bogus
 

I expect that isn't going to be the answer. 

However if there is only one source of funding in would seek to have more people involved in getting a single change complete over multiple things in progress. 

Hopefully one can get the agreement with the principle that there can only be one top priority. 

I don't have a formula to offer for that circumstance. 

On Mon, Feb 17, 2020, 4:35 PM russgold <russgold@...> wrote:
And if there is a single source of funding, what would you do with that information?

On Feb 17, 2020, at 4:33 PM, David Bogus <DavidBogus@...> wrote:

I would ask a few questions to understand the structer of the group. 

"Is there a single source of funding for all changes to the shared code base?"

If there are multiple sources of funding I would follow up with "Can any team members charge against any source without pre approval?"






On Mon, Feb 17, 2020, 1:11 PM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 




David Bogus
 

In the situation where multiple funding streams that not everybody can charge against. A team naturally devolves into a group that happens to share a code base. 

If that is the circumstance I'd typically start with getting all members able to charge each stream. 

This is usually easier or faster to do then merging the funding streams from the bottom up. 



On Mon, Feb 17, 2020, 7:32 PM David Bogus <davidbogus@...> wrote:
I expect that isn't going to be the answer. 

However if there is only one source of funding in would seek to have more people involved in getting a single change complete over multiple things in progress. 

Hopefully one can get the agreement with the principle that there can only be one top priority. 

I don't have a formula to offer for that circumstance. 

On Mon, Feb 17, 2020, 4:35 PM russgold <russgold@...> wrote:
And if there is a single source of funding, what would you do with that information?

On Feb 17, 2020, at 4:33 PM, David Bogus <DavidBogus@...> wrote:

I would ask a few questions to understand the structer of the group. 

"Is there a single source of funding for all changes to the shared code base?"

If there are multiple sources of funding I would follow up with "Can any team members charge against any source without pre approval?"






On Mon, Feb 17, 2020, 1:11 PM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 




Steve Berczuk
 

My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.

On Mon, Feb 17, 2020 at 1:11 PM J. B. Rainsberger <jbrains762@gmail.com> wrote:

Here is a Twitter exchange I had a while ago:

https://twitter.com/svarlet/status/1191375183141101568

When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done.

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation.

J. B. Rainsberger :: https://tdd.training | https://jbrains.ca | https://blog.thecodewhisperer.com
--
Steve Berczuk | steve.berczuk@gmail.com | http://www.berczuk.com | @sberczuk
SaneBox keeps my inbox clean, try it here: http://sanebox.com/t/87l4z


Brad Appleton
 

+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


Steve Gordon
 

A problem with developers working on different branches even with TDD and healthy feedback is that a solid, simplifying refactoring on one branch can break functionality on a different branch.  It is not a matter of the feasibility of resolving the problem during a subsequent merge, but that the team will learn to just not refactor during TDD, a habit which can create horrible code smells that eventually require large refactorings.  

I prefer to keep development on one branch, so we know immediately if something is breaking something else, which facilitates doing TDD properly (i.e., with frequent refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


Brad Appleton
 

Hi Steve! I've seen many situations like the one you describe. The problem isn't the branches here, its the frequency of integration (or lack thereof). The exact same problem exists even when you don't use (story) branches but still have long-lived (uncomitted) work in your version control workspace (i.e. local git repo, or subversion "copy", etc.). 

NOTE that what I call a "story branch" not an integration branch (there is no merging/integration to the story branch). So any integration/merges are still going to the same (single) main-trunk for integration. 

When you DO merge (integrate) to the main-trunk it is important that your workspace is now updated/refreshed with the integrated result ('git rebase' is really good for this). Otherwise, the problem you noted can still happen (and again, regardless of whether you were working on a story-branch).

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon <sgordonphd@...> wrote:
A problem with developers working on different branches even with TDD and healthy feedback is that a solid, simplifying refactoring on one branch can break functionality on a different branch.  It is not a matter of the feasibility of resolving the problem during a subsequent merge, but that the team will learn to just not refactor during TDD, a habit which can create horrible code smells that eventually require large refactorings.  

I prefer to keep development on one branch, so we know immediately if something is breaking something else, which facilitates doing TDD properly (i.e., with frequent refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


Steve Gordon
 

I coach check in and check back out at the end of each TDD cycle.  But, that is not sufficient if developers are working on different branches.


On Wed, Feb 19, 2020 at 4:18 PM Brad Appleton <Brad.Appleton@...> wrote:
Hi Steve! I've seen many situations like the one you describe. The problem isn't the branches here, its the frequency of integration (or lack thereof). The exact same problem exists even when you don't use (story) branches but still have long-lived (uncomitted) work in your version control workspace (i.e. local git repo, or subversion "copy", etc.). 

NOTE that what I call a "story branch" not an integration branch (there is no merging/integration to the story branch). So any integration/merges are still going to the same (single) main-trunk for integration. 

When you DO merge (integrate) to the main-trunk it is important that your workspace is now updated/refreshed with the integrated result ('git rebase' is really good for this). Otherwise, the problem you noted can still happen (and again, regardless of whether you were working on a story-branch).

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon <sgordonphd@...> wrote:
A problem with developers working on different branches even with TDD and healthy feedback is that a solid, simplifying refactoring on one branch can break functionality on a different branch.  It is not a matter of the feasibility of resolving the problem during a subsequent merge, but that the team will learn to just not refactor during TDD, a habit which can create horrible code smells that eventually require large refactorings.  

I prefer to keep development on one branch, so we know immediately if something is breaking something else, which facilitates doing TDD properly (i.e., with frequent refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


Steve Berczuk
 

I think what’s missing here is that code sitting on a developers machine is also isolated. As long as you merge all the code to master at “the right” cadence you should be fine. If Branches help with feedback they are better than not merging from your workspace on your machine. 

I’ve worked with people who didn’t use branches but also didn’t push changes til a large chunk or work was done. That’s not better. So I feel like the “to branch of not to branch” conversation deflects from the main issue, which is cycle time. 



-- 
Steve Berczuk

On February 19, 2020 at 6:31:33 PM, Steve Gordon (sgordonphd@...) wrote:

I coach check in and check back out at the end of each TDD cycle.  But, that is not sufficient if developers are working on different branches.

On Wed, Feb 19, 2020 at 4:18 PM Brad Appleton <Brad.Appleton@...> wrote:
Hi Steve! I've seen many situations like the one you describe. The problem isn't the branches here, its the frequency of integration (or lack thereof). The exact same problem exists even when you don't use (story) branches but still have long-lived (uncomitted) work in your version control workspace (i.e. local git repo, or subversion "copy", etc.). 

NOTE that what I call a "story branch" not an integration branch (there is no merging/integration to the story branch). So any integration/merges are still going to the same (single) main-trunk for integration. 

When you DO merge (integrate) to the main-trunk it is important that your workspace is now updated/refreshed with the integrated result ('git rebase' is really good for this). Otherwise, the problem you noted can still happen (and again, regardless of whether you were working on a story-branch).

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon <sgordonphd@...> wrote:
A problem with developers working on different branches even with TDD and healthy feedback is that a solid, simplifying refactoring on one branch can break functionality on a different branch.  It is not a matter of the feasibility of resolving the problem during a subsequent merge, but that the team will learn to just not refactor during TDD, a habit which can create horrible code smells that eventually require large refactorings.  

I prefer to keep development on one branch, so we know immediately if something is breaking something else, which facilitates doing TDD properly (i.e., with frequent refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


Rob Park
 

From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark


On Wed, Feb 19, 2020 at 7:37 PM Steve Berczuk <steve.berczuk@...> wrote:
I think what’s missing here is that code sitting on a developers machine is also isolated. As long as you merge all the code to master at “the right” cadence you should be fine. If Branches help with feedback they are better than not merging from your workspace on your machine. 

I’ve worked with people who didn’t use branches but also didn’t push changes til a large chunk or work was done. That’s not better. So I feel like the “to branch of not to branch” conversation deflects from the main issue, which is cycle time. 



-- 
Steve Berczuk

On February 19, 2020 at 6:31:33 PM, Steve Gordon (sgordonphd@...) wrote:

I coach check in and check back out at the end of each TDD cycle.  But, that is not sufficient if developers are working on different branches.

On Wed, Feb 19, 2020 at 4:18 PM Brad Appleton <Brad.Appleton@...> wrote:
Hi Steve! I've seen many situations like the one you describe. The problem isn't the branches here, its the frequency of integration (or lack thereof). The exact same problem exists even when you don't use (story) branches but still have long-lived (uncomitted) work in your version control workspace (i.e. local git repo, or subversion "copy", etc.). 

NOTE that what I call a "story branch" not an integration branch (there is no merging/integration to the story branch). So any integration/merges are still going to the same (single) main-trunk for integration. 

When you DO merge (integrate) to the main-trunk it is important that your workspace is now updated/refreshed with the integrated result ('git rebase' is really good for this). Otherwise, the problem you noted can still happen (and again, regardless of whether you were working on a story-branch).

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon <sgordonphd@...> wrote:
A problem with developers working on different branches even with TDD and healthy feedback is that a solid, simplifying refactoring on one branch can break functionality on a different branch.  It is not a matter of the feasibility of resolving the problem during a subsequent merge, but that the team will learn to just not refactor during TDD, a habit which can create horrible code smells that eventually require large refactorings.  

I prefer to keep development on one branch, so we know immediately if something is breaking something else, which facilitates doing TDD properly (i.e., with frequent refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived) branches (or even PRs), and long feedback cycles are sometimes more a result of larger change/batch-sizes (e.g., for "reviews), in which case the more fundamental problem is working in smaller (integratable+testable) chunks in shorter cycles (with more frequent commits during the lifetime of a story).

  • If I can get the team to practice TDD (or even BDD) I find that to be one of the best ways get them to work in smaller, testable chunks smaller chunks (especially if it gets them to commit at least per passed acceptance test/criteria). 
  • Even so, the idea that its okay to commit/integrate multiple times over the course of working on a story is HUGE, and can be difficult to overcome (too many seem to automatically assume that they should not commit until the whole story is completed, (regardless of whether a story/feature branch is used). That is the first thing I try to "nudge" toward in this case.
  • Often there is fear of having to UNmerge code that represents partially completed features (or stories) -- introducing feature-toggles can help here
  • If they're not ready (or willing) to do pair programming, sometimes they will still do pair *reviewing* (or in a triad rather than a pair) - sometimes that can be better forcing function for frequent feedback/interaction than doing all PRs as offline/async reviews. 
  • To that end I find it can help to block-out some times (or small rooms) for such "reviews" throughout the day (even if they are virtual), and if the code-changes arent too big. Then they can quickly do the reviews/PRs in those slots, and in smaller chunks, with strong encouragement ("nudging") to commit in smaller chunks.
In the end, I'm not focusing so much on nudging them away from branches, or even PRs, so much as I am nudging them towards working in smaller chunks, shorter feedback cycles, and more frequent commits (and more daily interaction as pairs or triads, at the story-level)



--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk <steve.berczuk@...> wrote:
My first thought is that the subject line here is misleading... The is
the long feedback cycle. If Pull Requests with quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of "Feature Branch" -- if a
feature really is a multi day bit of work, I agree than the practice
can cause issues.

I don't mean to distract from the other insights here, but I've heard
so many conversations about this that are the result of people using
words in different ways, and focusing on practices rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you have amazing
testing practices) and rapid integration are the things I look for.


George Dinwiddie
 

I tend to describe the problem as "How long is it between the time one developer makes a code change until all other developers accommodate that change in their code?" The longer that time, the less continuous the integration and the more integration pain.

As has been noted, this time can be lengthened in a number of ways:
- keeping changes in the developer's working copy
- keeping changes in local staging
- keeping changes in local repo
- keeping changes in separate branch from other developers
- not updating the developers working copy from the shared repo
The terminology varies, but the principle remains the same. Changes need to be merged into a shared repository, and then merged into each developer's working copy.

- George

On 2/19/20 9:16 PM, Rob Park wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.
@robpark
On Wed, Feb 19, 2020 at 7:37 PM Steve Berczuk <steve.berczuk@gmail.com <mailto:steve.berczuk@gmail.com>> wrote:
I think what’s missing here is that code sitting on a developers
machine is also isolated. As long as you merge all the code to
master at “the right” cadence you should be fine. If Branches help
with feedback they are better than not merging from your workspace
on your machine.
I’ve worked with people who didn’t use branches but also didn’t push
changes til a large chunk or work was done. That’s not better. So I
feel like the “to branch of not to branch” conversation deflects
from the main issue, which is cycle time.
--
Steve Berczuk
On February 19, 2020 at 6:31:33 PM, Steve Gordon
(sgordonphd@gmail.com <mailto:sgordonphd@gmail.com>) wrote:

I coach check in and check back out at the end of each TDD cycle. But, that is not sufficient if developers are working on
different branches.

On Wed, Feb 19, 2020 at 4:18 PM Brad Appleton
<Brad.Appleton@gmail.com <mailto:Brad.Appleton@gmail.com>> wrote:

Hi Steve! I've seen many situations like the one you describe.
The problem isn't the branches here, its the frequency of
integration (or lack thereof). The exact same problem exists
even when you don't use (story) branches but still have
long-lived (uncomitted) work in your version control workspace
(i.e. local git repo, or subversion "copy", etc.).

NOTE that what I call a "story branch" not an integration
branch (there is no merging/integration to the story branch).
So any integration/merges are still going to the same (single)
main-trunk for integration.

When you DO merge (integrate) to the main-trunk it is
important that your workspace is now updated/refreshed with
the integrated result ('git rebase' is really good for this).
Otherwise, the problem you noted can still happen (and again,
regardless of whether you were working on a story-branch).

--
/Brad Appleton <brad@bradapp.net <mailto:brad@bradapp.net>>/
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon
<sgordonphd@gmail.com <mailto:sgordonphd@gmail.com>> wrote:

A problem with developers working on different branches
even with TDD and healthy feedback is that a solid,
simplifying refactoring on one branch can break
functionality on a different branch.  It is not a matter
of the feasibility of resolving the problem during a
subsequent merge, but that the team will learn to just not
refactor during TDD, a habit which can create horrible
code smells that eventually require large refactorings.

I prefer to keep development on one branch, so we know
immediately if something is breaking something else, which
facilitates doing TDD properly (i.e., with frequent
refactoring where green means green).

On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton
<Brad.Appleton@gmail.com <mailto:Brad.Appleton@gmail.com>>
wrote:

+1 to what Steve said, plus my $0.02 ...

I agree that the underlying issue isn't (long-lived)
branches (or even PRs), and long feedback cycles are
sometimes more a result of larger change/batch-sizes
(e.g., for "reviews), in which case the more
fundamental problem is working in smaller
(integratable+testable) chunks in shorter cycles (with
more frequent commits during the lifetime of a story).

* If I can get the team to practice TDD (or even
BDD) I find that to be one of the best ways get
them to work in smaller, testable chunks smaller
chunks (especially if it gets them to commit at
least per passed acceptance test/criteria).

* Even so, the idea that its okay to
commit/integrate multiple times over the course of
working on a story is HUGE, and can be difficult
to overcome (too many seem to automatically assume
that they should not commit until the whole story
is completed, (regardless of whether a
story/feature branch is used). That is the first
thing I try to "nudge" toward in this case.

* Often there is fear of having to UNmerge code that
represents partially completed features (or
stories) -- introducing feature-toggles can help here

* If they're not ready (or willing) to do pair
programming, sometimes they will still do pair
*reviewing* (or in a triad rather than a pair) -
sometimes that can be better forcing function for
frequent feedback/interaction than doing all PRs
as offline/async reviews.

* To that end I find it can help to block-out some
times (or small rooms) for such "reviews"
throughout the day (even if they are virtual), and
if the code-changes arent too big. Then they can
quickly do the reviews/PRs in those slots, and in
smaller chunks, with strong encouragement
("nudging") to commit in smaller chunks.

In the end, I'm not focusing so much on nudging them
away from branches, or even PRs, so much as I am
nudging them towards working in smaller chunks,
shorter feedback cycles, and more frequent commits
(and more daily interaction as pairs or triads, at the
story-level)



--
/Brad Appleton <brad@bradapp.net
<mailto:brad@bradapp.net>>/
"And miles to go before I sleep" --Robert Frost


On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk
<steve.berczuk@gmail.com
<mailto:steve.berczuk@gmail.com>> wrote:

My first thought is that the subject line here is
misleading... The is
the long feedback cycle. If Pull Requests with
quick turn around times
work for a group, branches and PRs aren't bad.
Though it also depends on the definition of
"Feature Branch" -- if a
feature really is a multi day bit of work, I agree
than the practice
can cause issues.

I don't mean to distract from the other insights
here, but I've heard
so many conversations about this that are the
result of people using
words in different ways, and focusing on practices
rather than goals.
(Goals come first...) .

Human Feedback (unless, and sometimes even if, you
have amazing
testing practices) and rapid integration are the
things I look for.
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach
----------------------------------------------------------------------


Brad Appleton
 



On Wed, Feb 19, 2020 at 5:31 PM Steve Gordon <sgordonphd@...> wrote:
I check in and check back out at the end of each TDD cycle.  But, that is not sufficient if developers are working on different branches.
  
It's not sufficient either way (especially if there is needed merging). And if youre using a DVCS (like Git) it's still in the local repo (and not yet on the main-trunk in the central/master repo). [And I'm assuming "checkin" here means "commit", rather than per-file checkin, which is even more problematic]

As SteveB said, its about cycle-time, and how soon/frequent the changes are merged/committed to main-trunk (of the master-repo). Its not about the dev story/task branches:
  • Unmerged, uncommitted changes are just as isolated in the developer's workspace (or local repo) regardless of whether they are on a story|task-branch. 
  • And in both cases there is only one integration/merge operation needed to commit the changes to the main-trunk.
Ive seen this proven many times with data looking at MT2MT for a dev-change (Mean-Time to Main-Trunk). This is a measure of how long the dev work is "isolated" (unmerged) from the main-trunk (starting from dev first commenced work on the change).
  • The single biggest factor is how long the work is isolated/unmerged -- usually by waiting until story-development is complete before merging 
  • or (even worse) waiting until feature-complete (including all the stories of the feature) before merging the feature (feature-branch) to main-trunk
  • But if you develop & merge incrementally in micro-tasks (as you go), such as with TDD, then MT2MT is not dependent on the lifetime of the (task/story/feature) branch [nor on it's absence].

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost 


Brad Appleton
 

Hi Rob! 

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:
  • From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.
  • But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.
    • This leads to the mistaken conclusion that the problem is how long-lived a branch is.
    • Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
    • Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)



On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@...> wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark_._,_._,_


Brad Appleton
 

Thank you George! Exactly wrote (and much more concise than I :-)
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 5:12 AM George Dinwiddie <lists@...> wrote:
I tend to describe the problem as "How long is it between the time one
developer makes a code change until all other developers accommodate
that change in their code?" The longer that time, the less continuous
the integration and the more integration pain.

As has been noted, this time can be lengthened in a number of ways:
  - keeping changes in the developer's working copy
  - keeping changes in local staging
  - keeping changes in local repo
  - keeping changes in separate branch from other developers
  - not updating the developers working copy from the shared repo
The terminology varies, but the principle remains the same. Changes need
to be merged into a shared repository, and then merged into each
developer's working copy.

  - George



Rob Park
 

Sorry Brad, I'm not sure I follow your emphasis on Feature Branch definition?

But this "they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)" is 100% consistent with my experience.

All that's important in my mind is what's actually on the mainline/trunk/master. 
You can merge/rebase back to your branch all you want (if that was part of your implication?), but that only makes it easier for you to delay integrating back to trunk... 
and when you do, you'll impose a bigger amount of change on everyone else (if you delay). 

I like to make small (< 1d) merges into master for CI to build and CD to deploy (as much as I possibly can).
I also prefer everyone on the team use a similar strategy.

@robpark


On Thu, Feb 20, 2020 at 10:32 AM Brad Appleton <Brad.Appleton@...> wrote:
Hi Rob! 

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:
  • From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.
  • But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.
    • This leads to the mistaken conclusion that the problem is how long-lived a branch is.
    • Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
    • Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)



On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@...> wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark


Brad Appleton
 

Hi Rob! My emphasis on Feature definition stems from their drastically different meaning between the two sources cited. These days, the term "feature branch" has become so overloaded as to mean just about any branch at all. 
  • But there is a *BIG* difference between branches used primarily for integrating changes (from others), 
  • versus a branch-used for working/developing directly on (by a lone developer, or "programming-pair").
An integration-branch explicitly imposes an additional level/layer of integration. A dev-work branch does not - it's just an isolated/private (developer) workspace but with added visibility/transparency to the rest of the repository-users: it still isolates work-in-process, but in a visible, intention-revealing fashion (unlike a private workspace alone).

So while what's ultimately on mainline/main-trunk is what matters, the visibility of work-in-process (UNmainlined) is also of importance.
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 10:00 AM Rob Park <robert.d.park@...> wrote:
Sorry Brad, I'm not sure I follow your emphasis on Feature Branch definition?

But this "they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)" is 100% consistent with my experience.

All that's important in my mind is what's actually on the mainline/trunk/master. 
You can merge/rebase back to your branch all you want (if that was part of your implication?), but that only makes it easier for you to delay integrating back to trunk... 
and when you do, you'll impose a bigger amount of change on everyone else (if you delay). 

I like to make small (< 1d) merges into master for CI to build and CD to deploy (as much as I possibly can).
I also prefer everyone on the team use a similar strategy.

@robpark

On Thu, Feb 20, 2020 at 10:32 AM Brad Appleton <Brad.Appleton@...> wrote:
Hi Rob! 

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:
  • From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.
  • But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.
    • This leads to the mistaken conclusion that the problem is how long-lived a branch is.
    • Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
    • Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)



On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@...> wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark_._,_._,_


Rob Park
 

I guess I haven't seen that type of "integration" branch much other than the tofu style of (my branch -> dev branch -> test branch -> prod branch).

Where I'd agree that's a very different type of branch, they also cause problems with integration headaches and delays in deployment IME and it's best work away from them if at all possible.

On Thu, Feb 20, 2020 at 11:41 AM Brad Appleton <Brad.Appleton@...> wrote:
Hi Rob! My emphasis on Feature definition stems from their drastically different meaning between the two sources cited. These days, the term "feature branch" has become so overloaded as to mean just about any branch at all. 
  • But there is a *BIG* difference between branches used primarily for integrating changes (from others), 
  • versus a branch-used for working/developing directly on (by a lone developer, or "programming-pair").
An integration-branch explicitly imposes an additional level/layer of integration. A dev-work branch does not - it's just an isolated/private (developer) workspace but with added visibility/transparency to the rest of the repository-users: it still isolates work-in-process, but in a visible, intention-revealing fashion (unlike a private workspace alone).

So while what's ultimately on mainline/main-trunk is what matters, the visibility of work-in-process (UNmainlined) is also of importance.
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 10:00 AM Rob Park <robert.d.park@...> wrote:
Sorry Brad, I'm not sure I follow your emphasis on Feature Branch definition?

But this "they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)" is 100% consistent with my experience.

All that's important in my mind is what's actually on the mainline/trunk/master. 
You can merge/rebase back to your branch all you want (if that was part of your implication?), but that only makes it easier for you to delay integrating back to trunk... 
and when you do, you'll impose a bigger amount of change on everyone else (if you delay). 

I like to make small (< 1d) merges into master for CI to build and CD to deploy (as much as I possibly can).
I also prefer everyone on the team use a similar strategy.

@robpark

On Thu, Feb 20, 2020 at 10:32 AM Brad Appleton <Brad.Appleton@...> wrote:
Hi Rob! 

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:
  • From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.
  • But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.
    • This leads to the mistaken conclusion that the problem is how long-lived a branch is.
    • Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
    • Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)



On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@...> wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark


Brad Appleton
 

Responding to Rob's other comment:
 >> You can merge/rebase back to your branch all you want (if that was part of your implication?), 

It was not (apologies if that was unclear).
  • Rebasing *without* merging is still not merging (hence, the added cost-of-delay :-).
  • OTOH, merging *without* rebasing/updating your workspace (or branch) still leaves your workspace out-of-date (with the mainline) for any subsequent changes.
In terms of creating+deleting daily "mayfly branches", lets take the case of a "story" that takes 4 workdays to complete:

CASE 1 [with daily (mayfly) task-branches]: 
* 4 branch-creations,
* 4 merge-commits, 
* 4 branch deletions -- resulting in limited visibility in the repo of the story (both in-progress and afterward).
 == And either 4 workspace creations + 4 workspace deletions (one per mayfly-task)
 == OR, 1 workspace creation, followed by 4 workspace updates/rebases (one per merge-commit)
(deleting the workspace and recreating a new up-to-date one is a lot more time+overhead than update/rebase) 

CASE 2 [with a single story-branch, and daily integration]:
* 1 branch creation
* 4 merge-commits
* 4 updates/rebases (one per merge-commit)
* 1 workspace deletion (unless you reuse+reconfigure it for another story, in which case 0)


--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 10:40 AM Brad Appleton <brad.appleton@...> wrote:
Hi Rob! My emphasis on Feature definition stems from their drastically different meaning between the two sources cited. These days, the term "feature branch" has become so overloaded as to mean just about any branch at all. 
  • But there is a *BIG* difference between branches used primarily for integrating changes (from others), 
  • versus a branch-used for working/developing directly on (by a lone developer, or "programming-pair").
An integration-branch explicitly imposes an additional level/layer of integration. A dev-work branch does not - it's just an isolated/private (developer) workspace but with added visibility/transparency to the rest of the repository-users: it still isolates work-in-process, but in a visible, intention-revealing fashion (unlike a private workspace alone).

So while what's ultimately on mainline/main-trunk is what matters, the visibility of work-in-process (UNmainlined) is also of importance.
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 10:00 AM Rob Park <robert.d.park@...> wrote:
Sorry Brad, I'm not sure I follow your emphasis on Feature Branch definition?

But this "they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)" is 100% consistent with my experience.

All that's important in my mind is what's actually on the mainline/trunk/master. 
You can merge/rebase back to your branch all you want (if that was part of your implication?), but that only makes it easier for you to delay integrating back to trunk... 
and when you do, you'll impose a bigger amount of change on everyone else (if you delay). 

I like to make small (< 1d) merges into master for CI to build and CD to deploy (as much as I possibly can).
I also prefer everyone on the team use a similar strategy.

@robpark

On Thu, Feb 20, 2020 at 10:32 AM Brad Appleton <Brad.Appleton@...> wrote:
Hi Rob! 

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:
  • From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.
  • But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.
    • This leads to the mistaken conclusion that the problem is how long-lived a branch is.
    • Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
    • Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)



On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@...> wrote:
From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark_._,_._,_


Brad Appleton
 

On Thu, Feb 20, 2020 at 11:02 AM Rob Park <robert.d.park@...> wrote:
I guess I haven't seen that type of "integration" branch much

Still, it's exactly what Martin Fowler popularized as "Feature branch", as in (my workspace/branch --> feature-integration branch --> prod branch)

other than the tofu style of (my branch -> dev branch -> test branch -> prod branch).
 
That adds even more additional layers of integration (and more delay) -- as you noted. 

So yes, fewer integration-branches is better (ideally one). Tho I'm sometimes willing to overlook the use of a "deployment branch" (that strictly reflects the deployed versions/commits in production). 
  • I don't love it, but it can be done well/simply without too much extra overhead (even tho its easy to get it wrong, a LOT - ouch!!). 
  • It can make a lot more sense if the deployment-branch corresponds to an actual (production) version-control workspace (or even a distributed repository)


Where I'd agree that's a very different type of branch, they also cause problems with integration headaches and delays in deployment IME and it's best work away from them if at all possible.



Steve Berczuk
 

Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying
the same thing :)

On Thu, Feb 20, 2020 at 11:41 AM Brad Appleton <Brad.Appleton@gmail.com> wrote:

Hi Rob! My emphasis on Feature definition stems from their drastically different meaning between the two sources cited. These days, the term "feature branch" has become so overloaded as to mean just about any branch at all.

But there is a *BIG* difference between branches used primarily for integrating changes (from others),
versus a branch-used for working/developing directly on (by a lone developer, or "programming-pair").

An integration-branch explicitly imposes an additional level/layer of integration. A dev-work branch does not - it's just an isolated/private (developer) workspace but with added visibility/transparency to the rest of the repository-users: it still isolates work-in-process, but in a visible, intention-revealing fashion (unlike a private workspace alone).

So while what's ultimately on mainline/main-trunk is what matters, the visibility of work-in-process (UNmainlined) is also of importance.
--
Brad Appleton <brad@bradapp.net>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 10:00 AM Rob Park <robert.d.park@gmail.com> wrote:

Sorry Brad, I'm not sure I follow your emphasis on Feature Branch definition?

But this "they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)" is 100% consistent with my experience.

All that's important in my mind is what's actually on the mainline/trunk/master.
You can merge/rebase back to your branch all you want (if that was part of your implication?), but that only makes it easier for you to delay integrating back to trunk...
and when you do, you'll impose a bigger amount of change on everyone else (if you delay).

I like to make small (< 1d) merges into master for CI to build and CD to deploy (as much as I possibly can).
I also prefer everyone on the team use a similar strategy.

@robpark

On Thu, Feb 20, 2020 at 10:32 AM Brad Appleton <Brad.Appleton@gmail.com> wrote:

Hi Rob!

The "guidance for a long time has been to merge to 'mainline' at least once a day" (per developer, as opposed to per team) is not only spot on, I believe it was part Fowler's initial definition of CI (it was either "at least daily per developer" or else "more than daily per developer").

That said, it is VERY important to note the differences in meaning of "Feature branch" from the sources you cited:

From Fowler's Bliki on "Feature Branch" -- it refers to a feature *integration* branch, that stays isolated (unmerged to main) until the feature is complete. This most definitely is NOT inherently CI.

But Forsgren in "Accelerate" (and in the 2017-2019 "State of DevOps report:) uses the term differently, to refer to ANY kind of topic-branch (story/task/feature), even if it is for development (not integration) *AND* assumes they are never merged incrementally, but ONLY after completion of the story/task/feature.

This leads to the mistaken conclusion that the problem is how long-lived a branch is.
Not only that, but they even suggest that only short "Mayfly" task-branches (that live <= 1 workday) are okay (and to remove them after theyve been merged)
Such "mayfly" branches are in fact far more overhead then a simple story-branch, because with a story-branch, you don't have to create and then delete a branch for every single merge (so long as you still merge to mainline at least daily)




On Wed, Feb 19, 2020 at 8:17 PM Rob Park <robert.d.park@gmail.com> wrote:

From my perspective, both of these things are important.
Feature branches are inherently not CI and cause many other issues (Also see Accelerate by Forsgren).
I believe the guidance for a long time has been to merge to "mainline" at least once a day, because pushing large/multi-day chunks can cause all kinds of pain and problems.

@robpark
--
Steve Berczuk | steve.berczuk@gmail.com | http://www.berczuk.com | @sberczuk
SaneBox keeps my inbox clean, try it here: http://sanebox.com/t/87l4z


Brad Appleton
 

+1 to what SteveB said (especially that last paragraph). 

I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").

And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).

The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"  

If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
  1. Change-in-process often needs to be isolated, but still visible/transparent
  2. It also needs to be as small and frequent as possible
  3. And integrated as soon/fast as possible (without delay)
  4. Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
    • And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
"Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS. 

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying the same thing :)


Steve Gordon
 

It is the ambiguity of merge/integration that is confusing this conversation for me.

It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.

If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?



On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what SteveB said (especially that last paragraph). 

I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").

And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).

The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"  

If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
  1. Change-in-process often needs to be isolated, but still visible/transparent
  2. It also needs to be as small and frequent as possible
  3. And integrated as soon/fast as possible (without delay)
  4. Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
    • And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
"Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS. 

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying the same thing :)


Brad Appleton
 

Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that. 
I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).

Examples:
In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
  - If I do a commit in my workspace, it changes only my local copy (not the mainline).
  - I do NOT consider this to be a merge (nor integration), because ...
  • My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated). 
In Git, my workspace is a local repo.
  - If I do a commit of some changes I made (whether to main, or a task-branch) they are still local. 
  • My changes have not (yet) been incorporated into the central (master) repository, 
  • much less onto the same branch where other's changes are also being incorporated (or merged/integrated). 
   - Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.
  • this might be a "commit" -- BUT it is still not integration (or merging) in my view.
  • my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
  • there are no one else's changes being incorporated to the task (or story) branch
  • and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.
I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated. 

This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]

As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.). 
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
It is the ambiguity of merge/integration that is confusing this conversation for me.

It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.

If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?



On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what SteveB said (especially that last paragraph). 

I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").

And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).

The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"  

If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
  1. Change-in-process often needs to be isolated, but still visible/transparent
  2. It also needs to be as small and frequent as possible
  3. And integrated as soon/fast as possible (without delay)
  4. Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
    • And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
"Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS. 

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying the same thing :)


Charlie Poole
 

It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology. For
example, using GIT, I may "merge", "pull" or "rebase" in order to get
the changes made by other people. When I'm giving them my changes, I
usually "push" to a shared branch and then "merge" that branch into
master. But sometimes (rarely) I simply "push" my own copy of master.

Point is, from the team interaction point of view, there are only two
different things happening in the above: getting other people's
changes into my workspace and sharing my own changes with others.

Charlie

On Thu, Feb 20, 2020 at 11:37 AM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:

Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that.
I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).

Examples:
In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
- If I do a commit in my workspace, it changes only my local copy (not the mainline).
- I do NOT consider this to be a merge (nor integration), because ...

My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated).

In Git, my workspace is a local repo.
- If I do a commit of some changes I made (whether to main, or a task-branch) they are still local.

My changes have not (yet) been incorporated into the central (master) repository,
much less onto the same branch where other's changes are also being incorporated (or merged/integrated).

- Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.

this might be a "commit" -- BUT it is still not integration (or merging) in my view.
my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
there are no one else's changes being incorporated to the task (or story) branch
and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.

I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated.

This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]

As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.).
--
Brad Appleton <brad@bradapp.net>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:

It is the ambiguity of merge/integration that is confusing this conversation for me.

It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches. If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.

If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?



On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@gmail.com> wrote:

+1 to what SteveB said (especially that last paragraph).

I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").

And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).

The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"

If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).

Change-in-process often needs to be isolated, but still visible/transparent
It also needs to be as small and frequent as possible
And integrated as soon/fast as possible (without delay)
Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)

And the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)

"Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS.

--
Brad Appleton <brad@bradapp.net>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@gmail.com> wrote:

Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying the same thing :)


Brad Appleton
 

Okay - now that I've clarified what I mean by merging/merge-integration, I can more easily address your previous statements:

  >>  It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.

Agreed. All the merging/integrating should be to the same branch, in this case, "mainline" (also called "main-trunk", or just "trunk"). 
The key distinction here is: there is no merging/integration happening on working-branches (e.g., task-branches & story-branches).
  • There are certainly checkins/commits - but these are not merging/integration
  • Because there are no parallel/concurrent changes being committed to the same branch (and same workspace), during the same time-period (from different people and/or workstations).
This is why working-branches (task-branch, story-branch) are VERY DIFFERENT from integration-branches (feature-branch, release-branch, prod-branch, etc.)

  >> If there are different branches for the different stories or features that are being developed in parallel and then merged together later, ...
 
Ahhhh! the "merged together *later*" part is the crux of the misunderstanding here (emphasis on "later").

What if I DO have different branches for different stories, but they are NOT all merged *later*? 
  • What if each story-branch has its latest changes merged (to mainline/trunk) in real-time! Incrementally, as they happen (i.e. after each "green-bar").
  • I do NOT wait until later (when the story is "done") to merge the whole story
  • Instead I merge to mainline at green-bar (or small-task), sequentially, *throughout* the lifetime of the story's development!
This way, all merges are still to the same branch! (remember, that a checkin/commit to a working-branch (story or task) is NOT a merge/integration to the working-branch.
  • It's just a sequential revision with no concurrent/parallel changes in the working-branch.
  • The merge/integration is triggered when changes on the working-branch get committed to mainline/trunk.
Sometimes you may want every commit to the working-branch to (also) trigger a merge to trunk. 
And other times, I may checkin/commit to the working branch, just to checkpoint my work even tho it may not "build" yet, much less work correctly (in Git, I can always "squash" those checkins away before I merge-commit to trunk)

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 1:37 PM Brad Appleton via Groups.Io <Brad.Appleton=gmail.com@groups.io> wrote:
Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that. 
I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).

Examples:
In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
  - If I do a commit in my workspace, it changes only my local copy (not the mainline).
  - I do NOT consider this to be a merge (nor integration), because ...
  • My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated). 
In Git, my workspace is a local repo.
  - If I do a commit of some changes I made (whether to main, or a task-branch) they are still local. 
  • My changes have not (yet) been incorporated into the central (master) repository, 
  • much less onto the same branch where other's changes are also being incorporated (or merged/integrated). 
   - Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.
  • this might be a "commit" -- BUT it is still not integration (or merging) in my view.
  • my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
  • there are no one else's changes being incorporated to the task (or story) branch
  • and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.
I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated. 

This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]

As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.). 
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
It is the ambiguity of merge/integration that is confusing this conversation for me.

It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.

If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?



On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
+1 to what SteveB said (especially that last paragraph). 

I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").

And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).

The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"  

If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
  1. Change-in-process often needs to be isolated, but still visible/transparent
  2. It also needs to be as small and frequent as possible
  3. And integrated as soon/fast as possible (without delay)
  4. Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
    • And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
"Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS. 

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
Let me add to this that this is a common issue I see in a lot of these
discussions: people making a case using different definitions of the
term.
I'm often seeing "Feature Branch" to mean "story branch" which is to
say "a day or two of work by one, maybe 2 people"

Rather than discussing the pros/cons of feature branches, I think it
is more useful to focus on time and scope of work (and the modularity
of the system). (the definition issue is also a useful conversation,
but probably not what we are getting at).

As as aside, I had an exchange with someone (Thierry de Pauw, I
believe) where we agreed that 2 articles, his titled something like
"Feature branching is evil" and mine "Feature branching is not evil"
were saying the same thing :)


Brad Appleton
 

Charlie Poole writes:
  >>  It seems like we can't really talk about this without first defining a vocabulary that is independent of particular SCM technology.  

Yep! (Wouldn't it be GREAT if we had an SCM pattern language for that :-)
  >> from the team interaction point of view, there are only two different things happening in the above: 
  >>  -- getting other people's changes into my workspace 
  >>  -- and sharing my own changes with others  

like receiving (others) changes, and sending (shared) changes to others.

Tho I would argue there are also local/private changes (isolated) to my workspace, that are not yet consumable by others.

Sometimes it can be helpful to use vocabulary from distributed/parallel/concurrent systems to speak more precisely (and tool-agnostic).

At one point, I tried making a 2D table, where the columns were something like: people, (work)place, (work)space, change (task), code (files), time (interval), etc. and then each cell of each row would have a value of "same" or "different" (or '?' for DontKnow, or '*' for DontCare).
Then I tried to figure out what each row meant (parallel, versus concurrent, versus distributed, along with isolated/local or integrated/shared) and there various combinations (push, pull, sync, async, etc.)

 
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 2:15 PM Charlie Poole via Groups.Io <charliepoole=gmail.com@groups.io> wrote:
It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology. For
example, using GIT, I may "merge", "pull" or "rebase" in order to get
the changes made by other people. When I'm giving them my changes, I
usually "push" to a shared branch and then "merge" that branch into
master. But sometimes (rarely) I simply "push" my own copy of master.

Point is, from the team interaction point of view, there are only two
different things happening in the above: getting other people's
changes into my workspace and sharing my own changes with others.

Charlie

On Thu, Feb 20, 2020 at 11:37 AM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:
>
> Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that.
> I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).
>
> Examples:
> In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
>   - If I do a commit in my workspace, it changes only my local copy (not the mainline).
>   - I do NOT consider this to be a merge (nor integration), because ...
>
> My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
> In Git, my workspace is a local repo.
>   - If I do a commit of some changes I made (whether to main, or a task-branch) they are still local.
>
> My changes have not (yet) been incorporated into the central (master) repository,
> much less onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
>    - Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.
>
> this might be a "commit" -- BUT it is still not integration (or merging) in my view.
> my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
> there are no one else's changes being incorporated to the task (or story) branch
> and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.
>
> I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated.
>
> This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]
>
> As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.).
> --
> Brad Appleton <brad@...>
> "And miles to go before I sleep" --Robert Frost
>
>
> On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
>>
>> It is the ambiguity of merge/integration that is confusing this conversation for me.
>>
>> It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.
>>
>> If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?
>>
>>
>>
>> On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
>>>
>>> +1 to what SteveB said (especially that last paragraph).
>>>
>>> I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").
>>>
>>> And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).
>>>
>>> The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"
>>>
>>> If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
>>>
>>> Change-in-process often needs to be isolated, but still visible/transparent
>>> It also needs to be as small and frequent as possible
>>> And integrated as soon/fast as possible (without delay)
>>> Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
>>>
>>> And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
>>>
>>> "Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS.
>>>
>>> --
>>> Brad Appleton <brad@...>
>>> "And miles to go before I sleep" --Robert Frost
>>>
>>>
>>> On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
>>>>
>>>> Let me add to this that this is a common issue I see in a lot of these
>>>> discussions: people making a case using different definitions of the
>>>> term.
>>>> I'm often seeing "Feature Branch" to mean "story branch" which is to
>>>> say "a day or two of work by one, maybe 2 people"
>>>>
>>>> Rather than discussing the pros/cons of feature branches, I think it
>>>> is more useful to focus on time and scope of work (and the modularity
>>>> of the system). (the definition issue is also a useful conversation,
>>>> but probably not what we are getting at).
>>>>
>>>> As as aside, I had an exchange with someone (Thierry de Pauw, I
>>>> believe) where we agreed that 2 articles, his titled something like
>>>> "Feature branching is evil" and mine "Feature branching is not evil"
>>>> were saying the same thing :)
>
>




Rob Park
 

"that are not yet consumable by others" ... this is something I find is usually a trigger for "I should rethink how to do this" .. "how can I make it safe to merge"

On Thu, Feb 20, 2020 at 3:43 PM Brad Appleton via Groups.Io <Brad.Appleton=gmail.com@groups.io> wrote:
Charlie Poole writes:
  >>  It seems like we can't really talk about this without first defining a vocabulary that is independent of particular SCM technology.  

Yep! (Wouldn't it be GREAT if we had an SCM pattern language for that :-)
  >> from the team interaction point of view, there are only two different things happening in the above: 
  >>  -- getting other people's changes into my workspace 
  >>  -- and sharing my own changes with others  

like receiving (others) changes, and sending (shared) changes to others.

Tho I would argue there are also local/private changes (isolated) to my workspace, that are not yet consumable by others.

Sometimes it can be helpful to use vocabulary from distributed/parallel/concurrent systems to speak more precisely (and tool-agnostic).

At one point, I tried making a 2D table, where the columns were something like: people, (work)place, (work)space, change (task), code (files), time (interval), etc. and then each cell of each row would have a value of "same" or "different" (or '?' for DontKnow, or '*' for DontCare).
Then I tried to figure out what each row meant (parallel, versus concurrent, versus distributed, along with isolated/local or integrated/shared) and there various combinations (push, pull, sync, async, etc.)

 
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 2:15 PM Charlie Poole via Groups.Io <charliepoole=gmail.com@groups.io> wrote:
It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology. For
example, using GIT, I may "merge", "pull" or "rebase" in order to get
the changes made by other people. When I'm giving them my changes, I
usually "push" to a shared branch and then "merge" that branch into
master. But sometimes (rarely) I simply "push" my own copy of master.

Point is, from the team interaction point of view, there are only two
different things happening in the above: getting other people's
changes into my workspace and sharing my own changes with others.

Charlie

On Thu, Feb 20, 2020 at 11:37 AM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:
>
> Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that.
> I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).
>
> Examples:
> In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
>   - If I do a commit in my workspace, it changes only my local copy (not the mainline).
>   - I do NOT consider this to be a merge (nor integration), because ...
>
> My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
> In Git, my workspace is a local repo.
>   - If I do a commit of some changes I made (whether to main, or a task-branch) they are still local.
>
> My changes have not (yet) been incorporated into the central (master) repository,
> much less onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
>    - Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.
>
> this might be a "commit" -- BUT it is still not integration (or merging) in my view.
> my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
> there are no one else's changes being incorporated to the task (or story) branch
> and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.
>
> I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated.
>
> This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]
>
> As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.).
> --
> Brad Appleton <brad@...>
> "And miles to go before I sleep" --Robert Frost
>
>
> On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
>>
>> It is the ambiguity of merge/integration that is confusing this conversation for me.
>>
>> It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.
>>
>> If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?
>>
>>
>>
>> On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
>>>
>>> +1 to what SteveB said (especially that last paragraph).
>>>
>>> I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").
>>>
>>> And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).
>>>
>>> The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"
>>>
>>> If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
>>>
>>> Change-in-process often needs to be isolated, but still visible/transparent
>>> It also needs to be as small and frequent as possible
>>> And integrated as soon/fast as possible (without delay)
>>> Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
>>>
>>> And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
>>>
>>> "Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS.
>>>
>>> --
>>> Brad Appleton <brad@...>
>>> "And miles to go before I sleep" --Robert Frost
>>>
>>>
>>> On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
>>>>
>>>> Let me add to this that this is a common issue I see in a lot of these
>>>> discussions: people making a case using different definitions of the
>>>> term.
>>>> I'm often seeing "Feature Branch" to mean "story branch" which is to
>>>> say "a day or two of work by one, maybe 2 people"
>>>>
>>>> Rather than discussing the pros/cons of feature branches, I think it
>>>> is more useful to focus on time and scope of work (and the modularity
>>>> of the system). (the definition issue is also a useful conversation,
>>>> but probably not what we are getting at).
>>>>
>>>> As as aside, I had an exchange with someone (Thierry de Pauw, I
>>>> believe) where we agreed that 2 articles, his titled something like
>>>> "Feature branching is evil" and mine "Feature branching is not evil"
>>>> were saying the same thing :)
>
>




Steve Berczuk
 

On Thu, Feb 20, 2020 at 3:43 PM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:

Charlie Poole writes:
>> It seems like we can't really talk about this without first defining a vocabulary that is independent of particular SCM technology.

Yep! (Wouldn't it be GREAT if we had an SCM pattern language for that :-)
Like this? http://www.scmpatterns.com/book/SCMPatterns-RefCard.pdf


--
Steve Berczuk | steve.berczuk@gmail.com | http://www.berczuk.com | @sberczuk
SaneBox keeps my inbox clean, try it here: http://sanebox.com/t/87l4z


Charlie Poole
 

Back in my youth, SCM meant Source Code Management. I've fallen into
that trap before, I'm afraid.

On Thu, Feb 20, 2020 at 4:58 PM Steve Berczuk <steve.berczuk@gmail.com> wrote:

On Thu, Feb 20, 2020 at 3:43 PM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:

Charlie Poole writes:
>> It seems like we can't really talk about this without first defining a vocabulary that is independent of particular SCM technology.

Yep! (Wouldn't it be GREAT if we had an SCM pattern language for that :-)
Like this? http://www.scmpatterns.com/book/SCMPatterns-RefCard.pdf


--
Steve Berczuk | steve.berczuk@gmail.com | http://www.berczuk.com | @sberczuk
SaneBox keeps my inbox clean, try it here: http://sanebox.com/t/87l4z



Brad Appleton
 

Charlie Poole writes:
 >>  "that are not yet consumable by others" ... this is something I find is usually a trigger for "I should rethink how to do this" .. "how can I make it safe to merge" 

Sometimes it is ... but not at all for what I'm talking about! Consider a sufficiently small change done in true TDD/BDD fashion:
- Step 0: Think (Thank you James Shore and "Art of Agile")
- Step 1: Red-Bar (code a small test, and watch it fail ["not-compiling" qualifies as failing -- Thank you Uncle Bob!]
- Step 2: Green-bar (write just enough code to make the test PASS [no more, and no less])
- Step 3: Refactor (mercilessly, retesting after each refactoring attempt)

NOTICE HOW the (in-progress) change is *not* necessarily consumable (integration-worthy) at every single point in this cycle!!! (nor should it be!)
 - AT best, it is only integration-worthy (shareable/consumable) AFTER Step 2 (maybe even not until after Step 3)
 - HOWEVER, it may warrant checkin/checkpoint (into source-control) after ANY of the above steps.

FOR EXAMPLE ...

Step 0: Think 
 - no in-progress code changes yet. OR ...
 - Maybe Ive started (even finished) writing a Given-When-Then scenario in Cucumber (but maybe no executable code yet, or even method interface yet)
 - OR vice-versa (I have a proposed interface for a new method, but not yet a completed Gherkin Scenario)
 - OR maybe Ive at least got an interface *and* a scenario, and saved the resulting file (or feature-file)

*** NOTE: It's not even red-bar yet. Nonetheless ...
 - I still might want to checkin this intermediate file-revision (in source-control) 
 - I might even compile it (or run a quick scan/lint check) 
BUT I certainly wouldn't try to build yet, much less integrate (it might not even be 5minutes yet)

Step 1: Red Bar (I now have finished coding a small test, and watched it fail 
- again, it is still valid (and reasonable) to want to checkin/checkpoint to source-control at this time
- and yet its not consumable (we know it will break the build if we do).

At this point, there is still no indication that I need to *seriously* rethink (yet) how I'm making this change, or that I'm not doing a good-enough job of making it "safe to merge"

If anything, I'm working in even smaller (and *safer*) steps even just for this one TDD-cycle!!! (think red-green-clean AND lean+mean [what we used to call YAGNI + DTSTTCPW + OAOO back on Ward's wiki in the 90s]

Much as we like to call it *continuous* -- in reality, its still a series of discrete steps, even for just one very short TDD-cycle:
- The in-progress change cannot be consumable during every single second of a TDD-cycle, no matter how small.
-  Even tho it CAN (and should) be consumable at the end of each cycle (maybe even after Green-bar)

--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 5:11 PM Rob Park <robert.d.park@...> wrote:
"that are not yet consumable by others" ... this is something I find is usually a trigger for "I should rethink how to do this" .. "how can I make it safe to merge"

On Thu, Feb 20, 2020 at 3:43 PM Brad Appleton via Groups.Io <Brad.Appleton=gmail.com@groups.io> wrote:
Charlie Poole writes:
  >>  It seems like we can't really talk about this without first defining a vocabulary that is independent of particular SCM technology.  

Yep! (Wouldn't it be GREAT if we had an SCM pattern language for that :-)
  >> from the team interaction point of view, there are only two different things happening in the above: 
  >>  -- getting other people's changes into my workspace 
  >>  -- and sharing my own changes with others  

like receiving (others) changes, and sending (shared) changes to others.

Tho I would argue there are also local/private changes (isolated) to my workspace, that are not yet consumable by others.

Sometimes it can be helpful to use vocabulary from distributed/parallel/concurrent systems to speak more precisely (and tool-agnostic).

At one point, I tried making a 2D table, where the columns were something like: people, (work)place, (work)space, change (task), code (files), time (interval), etc. and then each cell of each row would have a value of "same" or "different" (or '?' for DontKnow, or '*' for DontCare).
Then I tried to figure out what each row meant (parallel, versus concurrent, versus distributed, along with isolated/local or integrated/shared) and there various combinations (push, pull, sync, async, etc.)

 
--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 2:15 PM Charlie Poole via Groups.Io <charliepoole=gmail.com@groups.io> wrote:
It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology. For
example, using GIT, I may "merge", "pull" or "rebase" in order to get
the changes made by other people. When I'm giving them my changes, I
usually "push" to a shared branch and then "merge" that branch into
master. But sometimes (rarely) I simply "push" my own copy of master.

Point is, from the team interaction point of view, there are only two
different things happening in the above: getting other people's
changes into my workspace and sharing my own changes with others.

Charlie

On Thu, Feb 20, 2020 at 11:37 AM Brad Appleton via Groups.Io
<Brad.Appleton=gmail.com@groups.io> wrote:
>
> Hi Steve! I agree there is a lot of misunderstanding/ambiguity surrounding integration (or merge-integration). I apologize for that.
> I think it is important to understand that not every checkin/commit is the same thing as integrating (or merging).
>
> Examples:
> In Subversion, a so called "copy" is both a workspace *and* a branch (even 'tags' in Subversion are a 'frozen' *copy*). So there is no distinction between a workspace versus a branch (which is good in some ways, bad in others)
>   - If I do a commit in my workspace, it changes only my local copy (not the mainline).
>   - I do NOT consider this to be a merge (nor integration), because ...
>
> My changes have not (yet) been incorporated onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
> In Git, my workspace is a local repo.
>   - If I do a commit of some changes I made (whether to main, or a task-branch) they are still local.
>
> My changes have not (yet) been incorporated into the central (master) repository,
> much less onto the same branch where other's changes are also being incorporated (or merged/integrated).
>
>    - Also, if I work on a local story/task branch in Git, even after I've done a local checkin/commit, if I then perform an operation that syncs my local branch to the corresponding story/task-branch in the central (master) repository.
>
> this might be a "commit" -- BUT it is still not integration (or merging) in my view.
> my task branch in the central-repo is little more than a mirror of the individual work in my local workspace (and branch).
> there are no one else's changes being incorporated to the task (or story) branch
> and those changes have not yet been incorporated into the same branch where other's changes are being incorporated.
>
> I do not consider it to be integration (nor merging) unless and until the work is being incorporated into a codeline where other changes reside and are also being incorporated.
>
> This, to me, is merging (or merge integration): when there are parallel/concurrent changes, from multiple workers (and workspaces) being incorporated into the same codeline [even if there were no changes to the same files, or no conflicting changes to the same files]
>
> As to the difference between merging vs integration, some folks consider merging to be part of the integration process, but that it also includes building and testing the merged result (for correctness/consistency/completeness, etc.).
> --
> Brad Appleton <brad@...>
> "And miles to go before I sleep" --Robert Frost
>
>
> On Thu, Feb 20, 2020 at 12:46 PM Steve Gordon via Groups.Io <sgordonphd=gmail.com@groups.io> wrote:
>>
>> It is the ambiguity of merge/integration that is confusing this conversation for me.
>>
>> It makes no difference how frequently developers are merging/integrating if they are merging/integrating to different branches.  If there are different branches for the different stories or features that are being developed in parallel and then merged together later, then we have the same problems that we would if each branch was on a different developer's workstation.
>>
>> If we do NOT have different branches for the different stories or features that are being developed in parallel, then why call them "feature branches" or "story branches"?
>>
>>
>>
>> On Thu, Feb 20, 2020 at 11:08 AM Brad Appleton <Brad.Appleton@...> wrote:
>>>
>>> +1 to what SteveB said (especially that last paragraph).
>>>
>>> I used to have a collection of links on the subject of "feature branch is/isNOT evil" and even "Feature branches vs. Feature Toggles" (which is a false dichotomy -- even when used correctly, with continuous/daily integration, they are each solutions to quite *different* problems). The list got very big, the ration of the ones ultimately saying the same thing became overwhelmed by the number of them using increasingly different definitions for "feature branch").
>>>
>>> And more recently (thanks in large part to the popularization of "Trunk-Based Development") it has turned into "ALL branching/branches are evil" which puts the focus on the wrong thing (branches) instead of on reducing (integration) delays and time-to-main, by working in smaller chunks and integrating more frequently/daily).
>>>
>>> The answer is NOT "NO Branching!" Rather, it's more like "*KNOW* Branching!"
>>>
>>> If you instead understand (lean) principles of "flow", and how version-control (including branches) are instances of change-flow, then it's much easier to see how to focus on making work visible/transparent, limiting work-in-process, optimizing flow/throughput (of value-delivery) and minimizing cost-of-delay (for integration, synchronization, and feedback).
>>>
>>> Change-in-process often needs to be isolated, but still visible/transparent
>>> It also needs to be as small and frequent as possible
>>> And integrated as soon/fast as possible (without delay)
>>> Whereas (integration) branches should be created as seldom as possible, and as late as feasible (at the last responsible moment)
>>>
>>> And  the more active integration branches you have at once, the more context-switching and multitasking you have (and more levels of indirection, creating more delay)
>>>
>>> "Working branches" (which are NOT integration branches) are really an extension of an individual workspace, that provide similar localization/isolation, but with more visible transparency of WIP in the VCS.
>>>
>>> --
>>> Brad Appleton <brad@...>
>>> "And miles to go before I sleep" --Robert Frost
>>>
>>>
>>> On Thu, Feb 20, 2020 at 11:27 AM Steve Berczuk <steve.berczuk@...> wrote:
>>>>
>>>> Let me add to this that this is a common issue I see in a lot of these
>>>> discussions: people making a case using different definitions of the
>>>> term.
>>>> I'm often seeing "Feature Branch" to mean "story branch" which is to
>>>> say "a day or two of work by one, maybe 2 people"
>>>>
>>>> Rather than discussing the pros/cons of feature branches, I think it
>>>> is more useful to focus on time and scope of work (and the modularity
>>>> of the system). (the definition issue is also a useful conversation,
>>>> but probably not what we are getting at).
>>>>
>>>> As as aside, I had an exchange with someone (Thierry de Pauw, I
>>>> believe) where we agreed that 2 articles, his titled something like
>>>> "Feature branching is evil" and mine "Feature branching is not evil"
>>>> were saying the same thing :)
>
>




Phil Goodwin
 

The degree to which the changes are cross cutting can be very important. I've worked on a couple of teams where the code base was large compared to the team size and merge conflicts were relatively rare. They liked developing big chunks of code on their own private branches and there was no talking them out of it because they weren't feeling any pain.

There were times when we'd scramble a little to get a cross-cutting change pushed to master and then pulled back out to our feature branches, but those were rare enough that they didn't impact the team's desire to retain their branch-and-pr culture. 



On Thu, Feb 20, 2020, 3:12 AM George Dinwiddie <lists@...> wrote:
I tend to describe the problem as "How long is it between the time one
developer makes a code change until all other developers accommodate
that change in their code?" The longer that time, the less continuous
the integration and the more integration pain.

As has been noted, this time can be lengthened in a number of ways:
  - keeping changes in the developer's working copy
  - keeping changes in local staging
  - keeping changes in local repo
  - keeping changes in separate branch from other developers
  - not updating the developers working copy from the shared repo
The terminology varies, but the principle remains the same. Changes need
to be merged into a shared repository, and then merged into each
developer's working copy.

  - George

On 2/19/20 9:16 PM, Rob Park wrote:
>  From my perspective, both of these things are important.
> Feature branches are inherently not CI and cause many other issues (Also
> see Accelerate by Forsgren).
> I believe the guidance for a long time has been to merge to "mainline"
> at least once a day, because pushing large/multi-day chunks can cause
> all kinds of pain and problems.
>
> @robpark
>
> On Wed, Feb 19, 2020 at 7:37 PM Steve Berczuk <steve.berczuk@...
> <mailto:steve.berczuk@...>> wrote:
>
>     I think what’s missing here is that code sitting on a developers
>     machine is also isolated. As long as you merge all the code to
>     master at “the right” cadence you should be fine. If Branches help
>     with feedback they are better than not merging from your workspace
>     on your machine.
>
>     I’ve worked with people who didn’t use branches but also didn’t push
>     changes til a large chunk or work was done. That’s not better. So I
>     feel like the “to branch of not to branch” conversation deflects
>     from the main issue, which is cycle time.
>
>
>
>     --
>     Steve Berczuk
>
>     On February 19, 2020 at 6:31:33 PM, Steve Gordon
>     (sgordonphd@... <mailto:sgordonphd@...>) wrote:
>
>>     I coach check in and check back out at the end of each TDD cycle.
>>     But, that is not sufficient if developers are working on
>>     different branches.
>>
>>     On Wed, Feb 19, 2020 at 4:18 PM Brad Appleton
>>     <Brad.Appleton@... <mailto:Brad.Appleton@...>> wrote:
>>
>>         Hi Steve! I've seen many situations like the one you describe.
>>         The problem isn't the branches here, its the frequency of
>>         integration (or lack thereof). The exact same problem exists
>>         even when you don't use (story) branches but still have
>>         long-lived (uncomitted) work in your version control workspace
>>         (i.e. local git repo, or subversion "copy", etc.).
>>
>>         NOTE that what I call a "story branch" not an integration
>>         branch (there is no merging/integration to the story branch).
>>         So any integration/merges are still going to the same (single)
>>         main-trunk for integration.
>>
>>         When you DO merge (integrate) to the main-trunk it is
>>         important that your workspace is now updated/refreshed with
>>         the integrated result ('git rebase' is really good for this).
>>         Otherwise, the problem you noted can still happen (and again,
>>         regardless of whether you were working on a story-branch).
>>
>>         --
>>         /Brad Appleton <brad@... <mailto:brad@...>>/
>>         "And miles to go before I sleep" --Robert Frost
>>
>>
>>         On Wed, Feb 19, 2020 at 5:05 PM Steve Gordon
>>         <sgordonphd@... <mailto:sgordonphd@...>> wrote:
>>
>>             A problem with developers working on different branches
>>             even with TDD and healthy feedback is that a solid,
>>             simplifying refactoring on one branch can break
>>             functionality on a different branch.  It is not a matter
>>             of the feasibility of resolving the problem during a
>>             subsequent merge, but that the team will learn to just not
>>             refactor during TDD, a habit which can create horrible
>>             code smells that eventually require large refactorings.
>>
>>             I prefer to keep development on one branch, so we know
>>             immediately if something is breaking something else, which
>>             facilitates doing TDD properly (i.e., with frequent
>>             refactoring where green means green).
>>
>>             On Wed, Feb 19, 2020 at 12:49 PM Brad Appleton
>>             <Brad.Appleton@... <mailto:Brad.Appleton@...>>
>>             wrote:
>>
>>                 +1 to what Steve said, plus my $0.02 ...
>>
>>                 I agree that the underlying issue isn't (long-lived)
>>                 branches (or even PRs), and long feedback cycles are
>>                 sometimes more a result of larger change/batch-sizes
>>                 (e.g., for "reviews), in which case the more
>>                 fundamental problem is working in smaller
>>                 (integratable+testable) chunks in shorter cycles (with
>>                 more frequent commits during the lifetime of a story).
>>
>>                   * If I can get the team to practice TDD (or even
>>                     BDD) I find that to be one of the best ways get
>>                     them to work in smaller, testable chunks smaller
>>                     chunks (especially if it gets them to commit at
>>                     least per passed acceptance test/criteria).
>>
>>                   * Even so, the idea that its okay to
>>                     commit/integrate multiple times over the course of
>>                     working on a story is HUGE, and can be difficult
>>                     to overcome (too many seem to automatically assume
>>                     that they should not commit until the whole story
>>                     is completed, (regardless of whether a
>>                     story/feature branch is used). That is the first
>>                     thing I try to "nudge" toward in this case.
>>
>>                   * Often there is fear of having to UNmerge code that
>>                     represents partially completed features (or
>>                     stories) -- introducing feature-toggles can help here
>>
>>                   * If they're not ready (or willing) to do pair
>>                     programming, sometimes they will still do pair
>>                     *reviewing* (or in a triad rather than a pair) -
>>                     sometimes that can be better forcing function for
>>                     frequent feedback/interaction than doing all PRs
>>                     as offline/async reviews.
>>
>>                   * To that end I find it can help to block-out some
>>                     times (or small rooms) for such "reviews"
>>                     throughout the day (even if they are virtual), and
>>                     if the code-changes arent too big. Then they can
>>                     quickly do the reviews/PRs in those slots, and in
>>                     smaller chunks, with strong encouragement
>>                     ("nudging") to commit in smaller chunks.
>>
>>                 In the end, I'm not focusing so much on nudging them
>>                 away from branches, or even PRs, so much as I am
>>                 nudging them towards working in smaller chunks,
>>                 shorter feedback cycles, and more frequent commits
>>                 (and more daily interaction as pairs or triads, at the
>>                 story-level)
>>
>>
>>
>>                 --
>>                 /Brad Appleton <brad@...
>>                 <mailto:brad@...>>/
>>                 "And miles to go before I sleep" --Robert Frost
>>
>>
>>                 On Wed, Feb 19, 2020 at 6:43 AM Steve Berczuk
>>                 <steve.berczuk@...
>>                 <mailto:steve.berczuk@...>> wrote:
>>
>>                     My first thought is that the subject line here is
>>                     misleading... The is
>>                     the long feedback cycle. If Pull Requests with
>>                     quick turn around times
>>                     work for a group, branches and PRs aren't bad.
>>                     Though it also depends on the definition of
>>                     "Feature Branch" -- if a
>>                     feature really is a multi day bit of work, I agree
>>                     than the practice
>>                     can cause issues.
>>
>>                     I don't mean to distract from the other insights
>>                     here, but I've heard
>>                     so many conversations about this that are the
>>                     result of people using
>>                     words in different ways, and focusing on practices
>>                     rather than goals.
>>                     (Goals come first...) .
>>
>>                     Human Feedback (unless, and sometimes even if, you
>>                     have amazing
>>                     testing practices) and rapid integration are the
>>                     things I look for.
>>
>

--
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach
  ----------------------------------------------------------------------





Brad Appleton
 


Hi Phil! Wholeheartedly agree about the degree to which changes are cross-cutting.

Another big part of that can be the physical organization of the repo-itself (i.e. file+folder structure).
- which code belongs in the same file with other code, or even the same folder
- and the resulting impacts to "the Seven Cs" ...
   -- coupling, cohesion, coherence, clarity, correctness, consistency *and* compile-time/commit-time.(make that 8 Cs :-)

THEN is the whole "monorepo" versus "manyrepos":
 - putting all applications (and/or [micro]services) into one big giant monster-size monorepo is recommended by Trunk-based Development author Paul Hammant
  •  yet this can GREATLY increase overall repo-size *and* create prohibitive clone/fork times, and even commit-times
  •  not to mention greatly increase the number of devs & teams trying to commit changes to the same repo (and integration-branch)
    • during the same time-interval (and same integration cycle of merge+compile+build+test)
    • causing a LOT of concurrent commit-contention (and delayed/blocked integration, or inconsistent/incomplete configurations)

ON the surface, it would make more sense to use many repos (i.e., one per application, [micro]service, or team) ...
  • this greatly reduced repo-size and clone/fork times, and commit/staging times
  • as well as number of devs working in the same repo (and merging to the same branch) during the same time
This can be a thorny issue for the occasional cross-cutting change (that must span more than one repo):
  • especially if every commit to ANY repo automatically triggers a CI-build
  • because for a cross-cutting change, you either have to sequence the commits to each repo in exactly the right order
  • OR else have some way to flag/mark when certain commits must NOT trigger a build 
  • (because it won't build successfully until *after* some other commit to a different repo)
  • tools like Buck, and Bazel can help with this [it's a thorny dependency and nested-transaction problem]
Still, such cross-cutting changes (spanning multiple repos) should be occasional at best (the exception rather than the rule)
-- and I'm not a big fan of using or justifying a big monorepo for what should be a small percentage of changes


--
Brad Appleton <brad@...>
"And miles to go before I sleep" --Robert Frost


On Thu, Feb 20, 2020 at 11:00 PM Phil Goodwin <phil.goodwin@...> wrote:
The degree to which the changes are cross cutting can be very important. I've worked on a couple of teams where the code base was large compared to the team size and merge conflicts were relatively rare. They liked developing big chunks of code on their own private branches and there was no talking them out of it because they weren't feeling any pain.

There were times when we'd scramble a little to get a cross-cutting change pushed to master and then pulled back out to our feature branches, but those were rare enough that they didn't impact the team's desire to retain their branch-and-pr culture. 


Todd Sedano
 



On Thu, Feb 20, 2020 at 12:15 PM Charlie Poole via Groups.Io <charliepoole=gmail.com@groups.io> wrote:
It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology.


Since git is the predominant tool that many of use, I think it’s fine using git commands to define what we mean. When discussing these concepts with coworkers, I usually talk about the commands they would type to achieve the desired goal.


Charlie Poole
 

Sure. Even so, I hear people say "merge" without saying what they are
merging and in what direction. In a team co-located team, it's easy:
just ask. Using structured communications (like here) assumptions are
sometimes made.

Charlie

On Fri, Feb 21, 2020 at 6:33 AM Todd Sedano <professor@gmail.com> wrote:



On Thu, Feb 20, 2020 at 12:15 PM Charlie Poole via Groups.Io <charliepoole=gmail.com@groups.io> wrote:

It seems like we can't really talk about this without first defining a
vocabulary that is independent of particular SCM technology.


Since git is the predominant tool that many of use, I think it’s fine using git commands to define what we mean. When discussing these concepts with coworkers, I usually talk about the commands they would type to achieve the desired goal.


Wouter Lagerweij
 

I've had varying levels of success with that move away from long lived branches.

I'd agree with what George raised: there's probably a larger issue in how the group/team works together.

Things that have been at least somewhat effective:
- Introducing a 'design chat' at the start of every story. This doesn't decrease story size, but creates alignment early on between a few team members, which can greatly reduce the discussion cycle in pull request. It's also my MMF for pairing:-)
- Doing katas with the express goal of exposing team members to other's coding styles: pair in the kata, but switch pairs and machines frequently. Again, not a batch size thing, but certainly a way to draw coding guidelines discussions out of the pull requests.
- Visualising pull requests on the board ('In Review'), and doing any of the ageing/queue detection things (daily dots on the card, etc.). Leading to explicit policies on handling reviews early.
- Mobbing with the team: builds empathy and trust in the team, shows everyone needs to look things up every now and again, shows the advantages of pairing, leads to smaller changes simply because of limitations in time ("what can we do in this half-day of mobbing?")
- Talk about risk and predictability with the team. Bus factor, knowledge sharing, size of stories vs sprint size and how that impact likelihood of 'failed' sprints
- Use the inevitable occasional big, messy, horrible merge: discuss how that can be avoided with smaller changes, and more frequent communication (ie merge) on what's happening in a branch.
- Put in a special build pipeline that merges all branches and breaks if there's conflicts (or test failures) to work-around late integration issues.
- Explicitly tell the team not to move to trunk based development because their quality (test coverage) is simply too low for that to be a pleasant experience for anyone. People love to prove you wrong;-)

Wouter


On Mon, Feb 17, 2020 at 7:11 PM J. B. Rainsberger <jbrains762@...> wrote:
Here is a Twitter exchange I had a while ago:


When I asked what problems the group in question were experiencing, Sébastien answered, "Individuals working solo for 10+ days on something, then open a PR which remains open for 10+ days because rest of the team is not available or because it’s too big to review quickly. I did explain factually and ran a pair programming experiment. While the benefits of the experiment were observed collectively, everyone defended that some work remains better done in solo (online search, docs, ...). This is acceptable and likely true yet was an excuse to start, and finish, anything in solo."

I suggested applying the principle of cutting a long feedback cycle in half, to see what would change and what the group would learn. One person wondered whether group members were hiding their ignorance (about something, anything) in their resistance to complete smaller tasks. Sébastien worries that the question of "smaller batches of work" would open a bigger can of worms, which, to be frank, it would and perhaps needs to be done. 

What would you suggest or want to ask Sébastien? Maybe we can get him here to join the conversation. 



--
Wouter Lagerweij          | wouter@...
linkedin.com/in/lagerweij | +31(0)6 28553506