<div dir="ltr">The team I've been working with for a year now functions on a slightly different, organic workflow. It's not unlike the one used in open source projects, which I find to be quite effective:<div><br></div>
<div>Everyday stuff:</div><div>- All commits go into master and are posted to campfire from github</div><div>- Anyone interested clicks the link, has a go through the code and either comments on github or brings issues up in campfire/IM</div>
<div>- If no one said anything, it probably didn't touch an important part of the code and was ignored, or everyone agrees with your changes</div><div>- Feedback is usually instant since a review is done on a per push basis.</div>
<div><br></div><div>Big, breaking changes:</div><div>- Commits are done to a branch</div><div>- Code until done, then:</div><div>- CI is run against the branch</div><div>- Pull request is created</div><div>- Another team member reviews the pull request and merges it</div>
<div>- We usually spend the next day fixing unforeseen issues anyway</div><div><br></div><div>Requirements for this to be successful and viable:</div><div><br></div><div>- No n00bz allowed on their own: The team is comprised only of experienced programmers who love what we do, know what we are doing, and care about the others enough not to allow crap into the code. Inexperienced programmers are welcome, but are under constant mentoring and have their code in a branch that is reviewed before merging.</div>
<div><br></div><div>- Staging environment: Although everything goes into master, it's not deployed to production. Production code is a separate branch that we bug fix on. Hopefully one day we will get our cucumbers to cover the whole of the app and trust them enough to promote anything that passes CI to production, working with feature toggles to shield users from unfinished functionality.</div>
<div><br></div><div>- Collective code ownership, individual accountability: We're free to change and poke around the whole of the codebase, but the person who wrote a piece originally has a certain attachment to it and a sense of responsibility for keeping it working and clean. If something bad happens, they're usually the ones fixing it.</div>
<div><br></div><div>- Awesome Product Owner: Your PO needs to understand that keeping a codebase healthy is as good to his pockets as is new functionality. Having them available at all times for answering questions and overhearing conversations on campfire is definitely a must have. Keeping the team accountable for bugs or big disruptions to other people's working environments should also be their job.</div>
<div><br></div><div>- Non-blaming culture: When something bad happens, no one asks "who screwed up?". We try and figure out who can fix the issue faster and give them every support they need.</div><div><br></div>
<div>- Small team: We're 5 people. Perhaps this could get a little chaotic if you're on a bigger team, but at that point, in my experience you should really give some thought at splitting teams up around functional areas (not technology!).</div>
<div><br></div><div>- Horizontal hierarchy - Not having anyone be "team lead/architect/tech lead/CTO/<insert fancy bossy title here>" is the best way to keep responsibility shared and everyone accountable. Again, in my experience, YMMV</div>
<div><br></div><div>Advantages (for me, YMMV):</div><div><br></div><div>- Fosters collaboration - everyone looks at all code being modified at all times; the team works as a unit to come up with solutions and keeping the codebase clean</div>
<div>- Enables remote work - since it revolves around Campfire, it's as easy to get your code constantly reviewed, same as if you were on site.</div><div>- Fluidness - No one sits around waiting for code to be reviewed. Sure, we need to wait for the PO to approve a piece of code, but since communication is very much open, the PO gets to see progress and give feedback even before code is integrated to master and pushed to staging.</div>
<div>- Team bonding - We're all in it together, responsibility is shared and we're all equally accountable for code quality and working software. Instead of thinking "oh damn, I have to go back and fix because person X dislikes this bit" a couple days after you've pushed, you get instant feedback and avoid the context switch</div>
<div><br></div><div>Hope you find it at least interesting, it's definitely diverging from most of what's been posted to this thread already. If you think we're insane for not doing feature branches, I suggest reading <a href="http://martinfowler.com/bliki/FeatureBranch.html">http://martinfowler.com/bliki/FeatureBranch.html</a> or watching <a href="http://www.youtube.com/watch?v=xzstASOvqNc">http://www.youtube.com/watch?v=xzstASOvqNc</a></div>
<div><br></div><div>Best,</div><div><br></div><div>Alex</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 20, 2013 at 8:21 PM, David Waller <span dir="ltr"><<a href="mailto:david.a.waller@btinternet.com" target="_blank">david.a.waller@btinternet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A bit late to add my 2p, but anyway...<br>
<br>
Context switching cost is almost impossible to avoid, but I've found that you can mitigate it in small ways<br>
- keep changes small so that they're fast to review<br>
- the team needs a shared commitment to not blocking each other<br>
- a reviewer shouldn't be pulling themselves out of a deep state of 'flow', but there are plenty of times when you're taking a lunch break, catching up on email, etc. when you can tack a code review onto the end.<br>

<br>
If you're doing continuous deployment or something along those lines, one of the key benefits is being able to turn round a fix in next to no time.  If maintaining that sort of feature/bugfix velocity is a priority for your team then much of what I've suggested comes simply as a beneficial side effect of that.<br>

<span class="HOEnZb"><font color="#888888"><br>
David<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div>