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_._,_._,_