https://citconf.com/wiki/api.php?action=feedcontributions&feedformat=atom&user=Douglassquirrel 2026-06-03T20:11:59Z User contributions MediaWiki 1.43.8 https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=16174 2016-03-28T11:31:42Z

<p>Douglassquirrel: </p> <hr /> <div>Consulting CTO and executive coach - in a few months, I can fix what's broken in a development team and grow its internal leadership. See http://douglassquirrel.com for more.<br /> <br /> I have attended every CITCON in Europe:<br /> <br /> * I helped with the [[One_Day_To_Live_Elephant_Carpaccio]] session at CITCON Helsinki 2015.<br /> * I helped with the [[How_to_be_awesome]], [[MicroservicesComboStyle]], and [[Normal_Accidents_and_Root_Cause_Analysis]] sessions at CITCON Zagreb 2014.<br /> * I helped with the [[Continuous_Rewriting]] session at CITCON Turin 2013.<br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am always happy to talk to anyone about any of the tools or ideas I discussed in these sessions.<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15994 2015-09-12T12:01:00Z

<p>Douglassquirrel: </p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org and https://en.m.wikipedia.org/wiki/Spaced_repetition)<br /> <br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> <br /> * 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1<br /> * nonsense<br /> * honest<br /> * honest &amp; complete<br /> * does the right thing<br /> * intent<br /> * domain abstraction<br /> <br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> <br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> <br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> <br /> 5. start measuring code coverage<br /> <br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> <br /> 7. larger modifications<br /> <br /> 8. mocking<br /> <br /> 9. modifictation to lighten the mocks<br /> <br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day<br /> <br /> Note mobbing works great to de-risk turnover and improve onboarding - a nine-year-old girl joined a mob and made a meaningful contribution as both driver and navigator<br /> <br /> Llewelyn has not tried remote mobbing, but has been tried with one remote person (in an experienced mob) at Hunter<br /> <br /> mobbing coaching tips https://github.com/isidore/AgileTechinicalCoaching/blob/master/Coaching%20CheatSheet.md</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15989 2015-09-12T11:55:08Z

<p>Douglassquirrel: </p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org and https://en.m.wikipedia.org/wiki/Spaced_repetition)<br /> <br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> <br /> * 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1<br /> * nonsense<br /> * honest<br /> * honest &amp; complete<br /> * does the right thing<br /> * intent<br /> * domain abstraction<br /> <br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> <br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> <br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> <br /> 5. start measuring code coverage<br /> <br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> <br /> 7. larger modifications<br /> <br /> 8. mocking<br /> <br /> 9. modifictation to lighten the mocks<br /> <br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day<br /> <br /> Note mobbing works great to de-risk turnover and improve onboarding - a nine-year-old girl joined a mob and made a meaningful contribution as both driver and navigator<br /> <br /> Llewelyn has not tried remote mobbing, but has been tried with one remote person (in an experienced mob) at Hunter</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15979 2015-09-12T11:42:47Z

<p>Douglassquirrel: </p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org and https://en.m.wikipedia.org/wiki/Spaced_repetition)<br /> <br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> <br /> * 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1<br /> * nonsense<br /> * honest<br /> * honest &amp; complete<br /> * does the right thing<br /> * intent<br /> * domain abstraction<br /> <br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> <br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> <br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> <br /> 5. start measuring code coverage<br /> <br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> <br /> 7. larger modifications<br /> <br /> 8. mocking<br /> <br /> 9. modifictation to lighten the mocks<br /> <br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15978 2015-09-12T11:38:45Z

<p>Douglassquirrel: </p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org)<br /> <br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> <br /> * 7 stages of naming - Belshee https://mobile.twitter.com/arlobelshee/status/636605852984545280/photo/1<br /> * nonsense<br /> * honest<br /> * honest &amp; complete<br /> * does the right thing<br /> * intent<br /> * domain abstraction<br /> <br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> <br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> <br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> <br /> 5. start measuring code coverage<br /> <br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> <br /> 7. larger modifications<br /> <br /> 8. mocking<br /> <br /> 9. modifictation to lighten the mocks<br /> <br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15977 2015-09-12T11:36:32Z

<p>Douglassquirrel: </p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org)<br /> <br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> <br /> * 7 stages of naming - Belshee<br /> * nonsense<br /> * honest<br /> * honest &amp; complete<br /> * does the right thing<br /> * intent<br /> * domain abstraction<br /> <br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> <br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> <br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> <br /> 5. start measuring code coverage<br /> <br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> <br /> 7. larger modifications<br /> <br /> 8. mocking<br /> <br /> 9. modifictation to lighten the mocks<br /> <br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Path_From_Legacy_Code_To_Unit_Tests&diff=15976 2015-09-12T11:30:26Z

<p>Douglassquirrel: Created page with &quot;Llewellyn Falco http://llewellynfalco.blogspot.co.uk 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org) 2. get into habit of extracting methods...&quot;</p> <hr /> <div>Llewellyn Falco http://llewellynfalco.blogspot.co.uk<br /> <br /> 1. organise team to do 2 hours of mob programming a day (see mobprogramming.org)<br /> 2. get into habit of extracting methods and renaming - that's all the mob does to start<br /> 7 stages of naming - Belshee<br /> nonsense<br /> honest<br /> honest &amp; complete<br /> does the right thing<br /> intent<br /> domain abstraction<br /> (Note TDD starts at end - domain abstraction - and works backward!)<br /> 3. repeat until you find a functional component (input-&gt;deterministic processing-&gt;output)<br /> 4. create unit test using poking. Determine what the functional component does by passing in simple, valid, self-documenting values like 0, 1, &quot;FirstName&quot;, &quot;FlightNumber&quot;, or even null. Whatever it returns (if not an exception) is right - put it into a test and check it in<br /> 5. start measuring code coverage<br /> 6. so far we have been extracting functional components by accident - now we can start making simple changes, like extracting parameters previously read from a web request, that make components functional<br /> 7. larger modifications<br /> 8. mocking<br /> 9. modifictation to lighten the mocks<br /> 10. now we can actually do a little bit of test-first!<br /> <br /> this takes a couple of months at 2 hours/day</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=CITCONEurope2015Sessions&diff=15975 2015-09-12T11:25:35Z

<p>Douglassquirrel: /* 2:00 Topics */</p> <hr /> <div>CITCON Europe 2015 Helsinki Sessions<br /> <br /> Back to the [[Main Page]]<br /> <br /> == 10:00 Topics ==<br /> <br /> # [[Test Tools The Next Generation]]<br /> # [[Advanced Unit Testing]]<br /> # [[One Day To Live Elephant Carpaccio]]<br /> # [[Alerts Everywhere]]<br /> # [[GIT Branching]]<br /> <br /> == 11:15 Topics ==<br /> <br /> # [[Dynamic CI Automatic Test Scope]]<br /> # [[Performance Testing]]<br /> # [[Why Should I Dockerize My App?]]<br /> # [[Manual QA Without Tears]]<br /> # [[Automation vs Security]]<br /> <br /> == Lunch Topics ==<br /> <br /> # [[...]]<br /> # [[...]]<br /> <br /> == 2:00 Topics ==<br /> <br /> # [[Test Automation Pyramid Adoption]]<br /> # [[Path From Legacy Code To Unit Tests]]<br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> <br /> == 3:15 Topics ==<br /> <br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> <br /> == 4:30 Topics ==<br /> <br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> # [[...]]<br /> <br /> == Table View ==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Room name<br /> ! 10:00<br /> ! 11:15<br /> ! 2:00<br /> ! 3:15<br /> ! 4:30<br /> |-<br /> | Auditorium <br /> | [[Test Tools The Next Generation]]<br /> | [[Dynamic CI Automatic Test Scope]]<br /> | [[...]]<br /> | [[...]]<br /> | [[...]]<br /> |-<br /> | 20<br /> | [[Advanced Unit Testing]]<br /> | [[Performance Testing]]<br /> | [[...]]<br /> | [[...]]<br /> | [[...]]<br /> |-<br /> | 16<br /> | [[One Day To Live Elephant Carpaccio]]<br /> | [[Why Should I Dockerize My App?]]<br /> | [[...]]<br /> | [[...]]<br /> | [[...]]<br /> |-<br /> | 18<br /> | [[Alerts Everywhere]]<br /> | [[Manual QA Without Tears]]<br /> | [[...]]<br /> | [[...]]<br /> | [[...]]<br /> |-<br /> | 14<br /> | [[GIT Branching]]<br /> | [[Automation vs Security]]<br /> | [[...]]<br /> | [[...]]<br /> | [[...]]<br /> |}</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15972 2015-09-12T09:14:54Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow - Gawande http://www.amazon.co.uk/The-Checklist-Manifesto-Things-Right/dp/1846683149<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf<br /> <br /> Little Black Book on test design Edgren - http://www.thetesteye.com/papers/TheLittleBlackBookOnTestDesign.pdf<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both<br /> <br /> One team spends one hour every morning on learning new things<br /> <br /> Tester pairing with dev can be silent but still trigger good testing behaviour - almost like a voodoo doll or cardboard cutout. To replicate more scalably, try setting time aside or make it fun - &quot;I know she will complain about this, better add a test!&quot;<br /> <br /> If you need to switch between developer and testing modes, go for coffee in between - it's a big switch!<br /> <br /> If bored when testing, that's a signal that something is wrong! Try some techniques to change it up: test with others (even random people found on twitter) or keep a log of your thoughts during the testing session<br /> <br /> Dice game taught by Bolton and Bach: http://www.bettertesting.co.uk/content/?p=438 - helps you get into an exploratory testing mode</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15971 2015-09-12T09:11:47Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow - Gawande http://www.amazon.co.uk/The-Checklist-Manifesto-Things-Right/dp/1846683149<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both<br /> <br /> One team spends one hour every morning on learning new things<br /> <br /> Tester pairing with dev can be silent but still trigger good testing behaviour - almost like a voodoo doll or cardboard cutout. To replicate more scalably, try setting time aside or make it fun - &quot;I know she will complain about this, better add a test!&quot;<br /> <br /> If you need to switch between developer and testing modes, go for coffee in between - it's a big switch!<br /> <br /> If bored when testing, that's a signal that something is wrong! Try some techniques to change it up: test with others (even random people found on twitter) or keep a log of your thoughts during the testing session<br /> <br /> Dice game taught by Bolton and Bach: http://www.bettertesting.co.uk/content/?p=438 - helps you get into an exploratory testing mode</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15970 2015-09-12T09:06:30Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow - Gawande http://www.amazon.co.uk/The-Checklist-Manifesto-Things-Right/dp/1846683149<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both<br /> <br /> One team spends one hour every morning on learning new things<br /> <br /> Tester pairing with dev can be silent but still trigger good testing behaviour - almost like a voodoo doll or cardboard cutout. To replicate more scalably, try setting time aside or make it fun - &quot;I know she will complain about this, better add a test!&quot;</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15969 2015-09-12T09:02:30Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow - Gawande http://www.amazon.co.uk/The-Checklist-Manifesto-Things-Right/dp/1846683149<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both<br /> <br /> One team spends one hour every morning on learning new things</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15968 2015-09-12T08:55:20Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both<br /> <br /> One team spends one hour every morning on learning new things</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15967 2015-09-12T08:51:51Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place http://www.amazon.co.uk/Perfect-Software-Other-Illusions-Testing/dp/0932633692<br /> <br /> Cheat Sheet by Hendrickson - test obsessed - http://testobsessed.com/2007/02/test-heuristics-cheat-sheet/<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge<br /> <br /> If a tester takes on writing technical tests, a danger is that he or she may stop or lose the skill to do manual tests - ensure they do both</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15966 2015-09-12T08:48:06Z

<p>Douglassquirrel: </p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> <br /> then introduce checklist for developers to follow<br /> <br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> <br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> <br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> <br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place<br /> <br /> Cheat Sheet by Hendrickson - test obsessed<br /> <br /> You Ain't done yet list<br /> <br /> Tester does part-time tech support to get context and knowledge</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Manual_QA_Without_Tears&diff=15964 2015-09-12T08:43:07Z

<p>Douglassquirrel: Created page with &quot;new tester - use exploratory testing charters, file bugs then introduce checklist for developers to follow try moving checklist to JIRA tickets you can assign to multiple peop...&quot;</p> <hr /> <div>new tester - use exploratory testing charters, file bugs<br /> then introduce checklist for developers to follow<br /> try moving checklist to JIRA tickets you can assign to multiple people (checklists can be better if used by many people, less checklist fatigue)<br /> introduce a best before date for checklist items, remove and see if problem comes back<br /> serendipity for tests: vary text used, persona simulated, avoid boredom and find more problems<br /> Jerry Wineberg: Perfect Software and other Illusions - uncovering what the software was supposed to do in the first place</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15950 2015-09-11T06:24:21Z

<p>Douglassquirrel: </p> <hr /> <div>Consulting CTO and executive coach - in a few months, I can fix what's broken in a development team and grow its internal leadership. See http://douglassquirrel.com for more.<br /> <br /> I have attended every CITCON in Europe:<br /> <br /> * I helped with the [[How_to_be_awesome]], [[MicroservicesComboStyle]], and [[Normal_Accidents_and_Root_Cause_Analysis]] sessions at CITCON Zagreb 2014.<br /> * I helped with the [[Continuous_Rewriting]] session at CITCON Turin 2013.<br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am always happy to talk to anyone about any of the tools or ideas I discussed in these sessions.<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15949 2015-09-11T06:17:48Z

<p>Douglassquirrel: </p> <hr /> <div>Consulting CTO and executive coach - in a few months, I can fix what's broken in a development team and grow its internal leadership. See http://douglassquirrel.com for more.<br /> <br /> I have attended every CITCON in Europe:<br /> <br /> * I helped with the [[Continuous_Rewriting]] session at CITCON Turin 2013.<br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am always happy to talk to anyone about any of the tools or ideas I discussed in these sessions.<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=MicroservicesComboStyle&diff=15743 2014-09-21T10:34:41Z

<p>Douglassquirrel: Created page with &quot;* What do we think micro services are.. * We want to be able to rewrite services and remove legacy code ** Make all &quot;objects&quot; separate processes that can run on diff...&quot;</p> <hr /> <div>* What do we think micro services are..<br /> * We want to be able to rewrite services and remove legacy code<br /> ** Make all &quot;objects&quot; separate processes that can run on different machines<br /> ** Rather than single process tight binding between classes<br /> ** We could run two of them on the same box to scale<br /> ** Ability to rewrite each object even using different languages if required<br /> ** Could communicate using direct RPC, e.g. as a fully meshed graph<br /> *** Would require agreement on contracts between objects<br /> *** Not favoured approach<br /> *** &quot;Orchestrated style&quot;<br /> ** Combo Model<br /> *** Tuple Spaces - Immutable data store<br /> *** Objects publish immutable facts to central store<br /> *** Objects can publish requests to store<br /> *** Other objects can publish responses to requests to store<br /> *** Objects interested in responses can take those and relay to end users/devices<br /> *** Basically it's pub/sub<br /> *** Can add other subscribers after the fact and consume existing events<br /> *** Promotes loose coupling<br /> *** &quot;Combo Style&quot;<br /> *** What about large messages, too large to pass round<br /> **** Upload the large payload to a repository e.g. via webservice<br /> **** Publish a &quot;pointer&quot; to the data<br /> *** Why not just do RPC to request data directly<br /> *** How do you handle errors<br /> **** If you don’t get a response in a given time frame there is a problem<br /> **** The client only needs to care the other service wsa unavailable and timed out, it should not concern itself with the specific error<br /> *** How do you handle say an order fulfilment scenario where the micro service handling fulfilment was down when the fulfilment request was sent<br /> **** In our case, each subscriber e.g the OrderProcessingService has its own unique persistent queue of messages it will resume processing when it starts up again<br /> *** How do you &quot;fix&quot; data<br /> **** E.g. order sent with wrong email<br /> **** We want to correct the email without double fullfiilling the order<br /> **** The order fulfilment step needs to be idempotent<br /> **** The email sending service would not be, it would send the confirmation email again regardless<br /> **** Each service will still hold its own state, or have its own database<br /> *** When would you switch a service to use queues/RabbitMQ<br /> * Prediction: 20/09/14 DS: Formal verification of microservices system proof, using COQ? &lt;- fix me</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=CITCONEurope2014Sessions&diff=15742 2014-09-21T10:31:40Z

<p>Douglassquirrel: /* 2:00 Topics */</p> <hr /> <div>CITCON Europe 2014 Zagreb Sessions<br /> <br /> Back to the [[Main Page]]<br /> <br /> == 10:00 Topics ==<br /> <br /> # [[Normal Accidents and Root Cause Analysis]]<br /> # [[big scale commit handling]]<br /> # [[polytesting]]<br /> # [[how to make the testing pyramid stand on its base]]<br /> <br /> == 11:15 Topics ==<br /> <br /> # [[working with large amounts of tests]]<br /> # [[?]]<br /> # [[CI CD 101]]<br /> # [[?]]<br /> <br /> == Lunch Topics ==<br /> <br /> # [[?]]<br /> <br /> == 2:00 Topics ==<br /> <br /> # [[?]]<br /> # [[MicroservicesComboStyle]]<br /> # [[Introduction to Puppet]]<br /> # [[packaging for deployment]]<br /> <br /> == 3:15 Topics ==<br /> <br /> # [[?]]<br /> # [[Security Testing]]<br /> # [[home brewing for process improvement]]<br /> # [[?]]<br /> <br /> == 4:30 Topics ==<br /> <br /> # [[?]]<br /> # [[?]]<br /> # [[?]]<br /> # [[?]]<br /> <br /> == Table View ==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Room name<br /> ! 10:00<br /> ! 11:15<br /> ! 2:00<br /> ! 3:15<br /> ! 4:30<br /> |-<br /> | Square<br /> | [[Normal Accidents and Root Cause Analysis]]<br /> | [[working with large amounts of tests]]<br /> | [[?]]<br /> | [[?]]<br /> | [[?]]<br /> |-<br /> | Long Room<br /> | [[big scale commit handling]]<br /> | [[?]]<br /> | [[?]]<br /> | [[Security Testing]]<br /> | [[?]]<br /> |-<br /> | Long Room Doors<br /> | [[polytesting]]<br /> | [[CI CD 101]]<br /> | [[Introduction to Puppet]]<br /> | [[?]]<br /> | [[?]]<br /> |-<br /> | Entry<br /> | [[how to make the testing pyramid stand on its base]]<br /> | [[?]]<br /> | [[?]]<br /> | [[?]]<br /> | [[?]]<br /> |}</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Normal_Accidents_and_Root_Cause_Analysis&diff=15741 2014-09-21T10:00:30Z

<p>Douglassquirrel: </p> <hr /> <div>Normal Accidents book: http://press.princeton.edu/titles/6596.html<br /> <br /> Systems are categorized by Interactions that are Simple vs Complex, and Tightly Coupled vs Loosely Coupled. <br /> <br /> There are a few different versions of the quadrant: http://paei.wdfiles.com/local--files/perrow-charles-normal-accident-theory/PAEI_043_Perrow_Normal_Accident_Theory.gif https://www.flickr.com/photos/metanick/139214026/ http://media.peakprosperity.com/images/3-Perrow-from-Accidents-Normal.png<br /> <br /> [[Douglas Squirrel]] talking about root-cause analysis: https://skillsmatter.com/skillscasts/1986-talk-by-squirrel<br /> <br /> Notes on Squirrel's talk: http://www.markhneedham.com/blog/2011/12/10/the-5-whysroot-cause-analysis-douglas-squirrel/<br /> <br /> Notes from John Bradshaw:<br /> <br /> Normal accidents:<br /> * 3 Mile Island Accident - Blamed Operators<br /> * Any system can and will fail, and you should plan for it to fail<br /> * 2 Axis graph<br /> ** Complexity -&gt; Simple<br /> ** Loose Coupling -&gt; Tight Coupling<br /> ** Complex &amp; Tightly Coupled = Accident<br /> * Complex system that is Loosely coupled is the CITCON open space set up evening<br /> ** We did not all rush to get food and beer<br /> * E.g had there been a Lion in there, 1 person could have warned rest<br /> * Chance to warn of danger<br /> * Simple but tightly coupled = Dam<br /> ** Accident is water gets through the damn<br /> ** Anything goes wrong with dam e.g. hole, no chance to resolve<br /> ** Simple to reason about, wall of rock with a hole in<br /> ** But is high risk<br /> * In nuclear plant accident, cooling system near radioactive rods<br /> ** Operators can see there was a leak, but no context e.g. they can see the leak is leaking near/into the radioactive rod storage which would lead to an accident<br /> * Book to Read: Normal Accidents by Perrow<br /> * Are micro services tightly coupled and complex?<br /> ** Depends<br /> ** It's down to design and implementation<br /> * Always strive to be in the bottom right corner of the graph, low complexity loosely coupled<br /> * How do people plan for failure?<br /> ** Rob - We go through a certification process to get into Retail<br /> * Each system that could fail is tested, e.g. chaos monkey style someone will manually go take down services<br /> * Internal team will run same tests internally before handing over to external certification team<br /> <br /> How do you verify or even test your logging? Instance of a service that logged every time on failure, in a tight loop and filled the disks leading to further failure = Simple Tightly Coupled System<br /> <br /> <br /> Root Cause Analysis<br /> <br /> Scenario: Database deliberately down for maintenance. Instance of a service that logged every time on failure connecting to database, in a tight loop and filled the disks leading to further failure<br /> <br /> * Basic principals<br /> ** Everybody who was affected comes to the meeting<br /> * To identity cultural or people problems<br /> * Not allowed to place blame<br /> * Ask/poll everyone what was the problem<br /> ** Customer:<br /> *** No system, was down, can't log on<br /> ** Operations:<br /> *** Confused by phone call<br /> ** Customer Service:<br /> *** Angry calls from customers, did not know what was going on<br /> ** Developer:<br /> *** Database down, no disk space<br /> *** Then ask why:<br /> ** Customer:<br /> ** Operations:<br /> ** Customer Service:<br /> ** Developer:<br /> *** Why: Maintenance on database, database down<br /> *** Why: Analysed log files, saw huge files, checked code, logged with no delay<br /> *** Why: Developer skills lacking<br /> *** Why: No code review/inspection<br /> *** Why: Test for this logging case lacking<br /> *** When QA tested database was running<br /> *** QA too busy to investigate database failures cases<br /> *** No new blood in organisation<br /> *** QA assigned/overbooked to too many projects<br /> *** Action: Maintenance on DB, have redundant database to switch to<br /> *** Action: QA involved earlier<br /> <br /> * Actions must be assigned and completed with a timeframe e.g. 1 week<br /> * When you hit that uncomfortable silence half way down, keep pushing<br /> <br /> <br /> <br /> <br /> * The root cause of failure is always the culture in an organisation<br /> * It’s always about people e.g.<br /> ** The developer adding no delay to logging<br /> ** Lack of testing<br /> * Create a RCA timeline of failure<br /> ** At what time did system go down<br /> ** At what time did customers complain<br /> ** At what time did developers react<br /> ** At what time was the system back up<br /> ** Etc<br /> * Do as much technical investigation as possible before the RCA meeting<br /> ** Eg this was the problem<br /> ** We had these tests<br /> *** But we didn’t have one for this scenario</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Normal_Accidents_and_Root_Cause_Analysis&diff=15740 2014-09-21T09:58:50Z

<p>Douglassquirrel: </p> <hr /> <div>Normal Accidents book: http://press.princeton.edu/titles/6596.html<br /> <br /> Systems are categorized by Interactions that are Simple vs Complex, and Tightly Coupled vs Loosely Coupled. <br /> <br /> There are a few different versions of the quadrant: http://paei.wdfiles.com/local--files/perrow-charles-normal-accident-theory/PAEI_043_Perrow_Normal_Accident_Theory.gif https://www.flickr.com/photos/metanick/139214026/ http://media.peakprosperity.com/images/3-Perrow-from-Accidents-Normal.png<br /> <br /> [[Douglas Squirrel]] talking about root-cause analysis: https://skillsmatter.com/skillscasts/1986-talk-by-squirrel<br /> <br /> Notes on Squirrel's talk: http://www.markhneedham.com/blog/2011/12/10/the-5-whysroot-cause-analysis-douglas-squirrel/<br /> <br /> Notes from John Bradshaw:<br /> <br /> Normal accidents:<br /> * 3 Mile Island Accident - Blamed Operators<br /> * Any system can and will fail, and you should plan for it to fail<br /> * 2 Axis graph<br /> ** Complexity -&gt; Simple<br /> ** Loose Coupling -&gt; Tight Coupling<br /> ** Complex &amp; Tightly Coupled = Accident<br /> * Complex system that is Loosely coupled is the CITCON open space set up evening<br /> ** We did not all rush to get food and beer<br /> * E.g had there been a Lion in there, 1 person could have warned rest<br /> * Chance to warn of danger<br /> * Simple but tightly coupled = Dam<br /> ** Accident is water gets through the damn<br /> ** Anything goes wrong with dam e.g. hole, no chance to resolve<br /> ** Simple to reason about, wall of rock with a hole in<br /> ** But is high risk<br /> * In nuclear plant accident, cooling system near radioactive rods<br /> ** Operators can see there was a leak, but no context e.g. they can see the leak is leaking near/into the radioactive rod storage which would lead to an accident<br /> * Book to Read: Normal Accidents by Perrow<br /> * Are micro services tightly coupled and complex?<br /> ** Depends<br /> ** It's down to design and implementation<br /> * Always strive to be in the bottom right corner of the graph, low complexity loosely coupled<br /> * How do people plan for failure?<br /> ** Rob - We go through a certification process to get into Retail<br /> * Each system that could fail is tested, e.g. chaos monkey style someone will manually go take down services<br /> * Internal team will run same tests internally before handing over to external certification team<br /> <br /> How do you verify or even test your logging? Instance of a service that logged every time on failure, in a tight loop and filled the disks leading to further failure = Simple Tightly Coupled System<br /> <br /> <br /> Root Cause Analysis<br /> <br /> Scenario: Database deliberately down for maintenance. Instance of a service that logged every time on failure connecting to database, in a tight loop and filled the disks leading to further failure<br /> <br /> * Basic principals<br /> ** Everybody who was affected comes to the meeting<br /> * To identity cultural or people problems<br /> * Not allowed to place blame<br /> * Ask/poll everyone what was the problem<br /> ** Customer:<br /> *** No system, was down, can't log on<br /> ** Operations:<br /> *** Confused by phone call<br /> ** Customer Service:<br /> *** Angry calls from customers, did not know what was going on<br /> ** Developer:<br /> *** Database down, no disk space<br /> *** Then ask why:<br /> ** Customer:<br /> ** Operations:<br /> ** Customer Service:<br /> ** Developer:<br /> · Why: Maintenance on database, database down<br /> · Why: Analysed log files, saw huge files, checked code, logged with no delay<br /> · Why: Developer skills lacking<br /> · Why: No code review/inspection<br /> · Why: Test for this logging case lacking<br /> · When QA tested database was running<br /> · QA too busy to investigate database failures cases<br /> · No new blood in organisation<br /> · QA assigned/overbooked to too many projects<br /> · Action: Maintenance on DB, have redundant database to switch to<br /> · Action: QA involved earlier<br /> <br /> § Actions must be assigned and completed with a timeframe e.g. 1 week<br /> § When you hit that uncomfortable silence half way down, keep pushing<br /> <br /> <br /> <br /> <br /> · The root cause of failure is always the culture in an organisation<br /> o It’s always about people e.g.<br /> · The developer adding no delay to logging<br /> · Lack of testing<br /> · Create a RCA timeline of failure<br /> o At what time did system go down<br /> o At what time did customers complain<br /> o At what time did developers react<br /> o At what time was the system back up<br /> o Etc<br /> · Do as much technical investigation as possible before the RCA meeting<br /> o Eg this was the problem<br /> o We had these tests<br /> · But we didn’t have one for this scenario</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Normal_Accidents_and_Root_Cause_Analysis&diff=15739 2014-09-21T09:54:40Z

<p>Douglassquirrel: </p> <hr /> <div>Normal Accidents book: http://press.princeton.edu/titles/6596.html<br /> <br /> Systems are categorized by Interactions that are Simple vs Complex, and Tightly Coupled vs Loosely Coupled. <br /> <br /> There are a few different versions of the quadrant: http://paei.wdfiles.com/local--files/perrow-charles-normal-accident-theory/PAEI_043_Perrow_Normal_Accident_Theory.gif https://www.flickr.com/photos/metanick/139214026/ http://media.peakprosperity.com/images/3-Perrow-from-Accidents-Normal.png<br /> <br /> [[Douglas Squirrel]] talking about root-cause analysis: https://skillsmatter.com/skillscasts/1986-talk-by-squirrel<br /> <br /> Notes on Squirrel's talk: http://www.markhneedham.com/blog/2011/12/10/the-5-whysroot-cause-analysis-douglas-squirrel/<br /> <br /> Notes from John Bradshaw:<br /> <br /> Normal accidents:<br /> · 3 Mile Island Accident - Blamed Operators<br /> · Any system can and will fail, and you should plan for it to fail<br /> · 2 Axis graph<br /> o Complexity -&gt; Simple<br /> o Loose Coupling -&gt; Tight Coupling<br /> o Complex &amp; Tightly Coupled = Accident<br /> · Complex system that is Loosely coupled is the CITCON open space set up evening<br /> o We did not all rush to get food and beer<br /> · E.g had there been a Lion in there, 1 person could have warned rest<br /> · Chance to warn of danger<br /> · Simple but tightly coupled = Dam<br /> o Accident is water gets through the damn<br /> o Anything goes wrong with dam e.g. hole, no chance to resolve<br /> o Simple to reason about, wall of rock with a hole in<br /> o But is high risk<br /> · In nuclear plant accident, cooling system near radioactive rods<br /> o Operators can see there was a leak, but no context e.g. they can see the leak is leaking near/into the radioactive rod storage which would lead to an accident<br /> · Book to Read: Normal Accidents by Perrow<br /> · Are micro services tightly coupled and complex?<br /> o Depends<br /> o It's down to design and implementation<br /> · Always strive to be in the bottom right corner of the graph, low complexity loosely coupled<br /> · How do people plan for failure?<br /> o Rob - We go through a certification process to get into Retail<br /> · Each system that could fail is tested, e.g. chaos monkey style someone will manually go take down services<br /> · Internal team will run same tests internally before handing over to external certification team<br /> <br /> How do you verify or even test your logging? Instance of a service that logged every time on failure, in a tight loop and filled the disks leading to further failure = Simple Tightly Coupled System<br /> <br /> <br /> Root Cause Analysis<br /> <br /> Scenario: Database deliberately down for maintenance. Instance of a service that logged every time on failure connecting to database, in a tight loop and filled the disks leading to further failure<br /> <br /> · Basic principals<br /> o Everybody who was affected comes to the meeting<br /> · To identity cultural or people problems<br /> · Not allowed to place blame<br /> · Ask/poll everyone what was the problem<br /> § Customer:<br /> · No system, was down, can't log on<br /> § Operations:<br /> · Confused by phone call<br /> § Customer Service:<br /> · Angry calls from customers, did not know what was going on<br /> § Developer:<br /> · Database down, no disk space<br /> · Then ask why:<br /> § Customer:<br /> § Operations:<br /> § Customer Service:<br /> § Developer:<br /> · Why: Maintenance on database, database down<br /> · Why: Analysed log files, saw huge files, checked code, logged with no delay<br /> · Why: Developer skills lacking<br /> · Why: No code review/inspection<br /> · Why: Test for this logging case lacking<br /> · When QA tested database was running<br /> · QA too busy to investigate database failures cases<br /> · No new blood in organisation<br /> · QA assigned/overbooked to too many projects<br /> · Action: Maintenance on DB, have redundant database to switch to<br /> · Action: QA involved earlier<br /> <br /> § Actions must be assigned and completed with a timeframe e.g. 1 week<br /> § When you hit that uncomfortable silence half way down, keep pushing<br /> <br /> <br /> <br /> <br /> · The root cause of failure is always the culture in an organisation<br /> o It’s always about people e.g.<br /> · The developer adding no delay to logging<br /> · Lack of testing<br /> · Create a RCA timeline of failure<br /> o At what time did system go down<br /> o At what time did customers complain<br /> o At what time did developers react<br /> o At what time was the system back up<br /> o Etc<br /> · Do as much technical investigation as possible before the RCA meeting<br /> o Eg this was the problem<br /> o We had these tests<br /> · But we didn’t have one for this scenario</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15694 2014-09-19T07:30:45Z

<p>Douglassquirrel: </p> <hr /> <div>VP Technology at Osper - we give kids from 8 to 18 a real debit card to help them learn about money.<br /> <br /> I have attended every CITCON in Europe:<br /> <br /> * I helped with the [[Continuous_Rewriting]] session at CITCON Turin 2013.<br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am always happy to talk to anyone about any of the tools or ideas I discussed in these sessions.<br /> <br /> Personal site: http://douglassquirrel.com<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15693 2014-09-19T07:26:38Z

<p>Douglassquirrel: </p> <hr /> <div>VP Technology at Osper - we give kids from 8 to 18 a real debit card to help them learn about money.<br /> <br /> I have attended every CITCON in Europe:<br /> <br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am always happy to talk to anyone about any of the tools or ideas I talked about in these sessions.<br /> <br /> Personal site: http://douglassquirrel.com<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_Rewriting&diff=15512 2013-09-28T15:40:08Z

<p>Douglassquirrel: /* How? Theory */</p> <hr /> <div>= Continuos Rewriting =<br /> <br /> CITCON Europe 2013 4:30-5:30 pm topic. See also [[Continuous rewriting]] session from CITCON Europe 2012 Budapest.<br /> <br /> <br /> == Why? ==<br /> <br /> Business people find smart people that write a lot of crappy code fast. The code does the job done, but it really needs to be rewritten. If you have read Joel Spolsky's blog post on how completely rewriting the code is really really (really) bad, then you know it is not what needs to be done.<br /> <br /> The speaker found himself several times in a situation to start working on a project that is in a &quot;needs rewrite desperately&quot; mode. What if we could rewrite continuously?<br /> <br /> Every week, even if the code is not broken, we rewrite a piece of code. After a while, all code base will be rewritten. We might not use the rewritten code. <br /> <br /> One has to invest a amount of time to do that.<br /> <br /> You can rewrite a piece of PHP application in Ruby, another piece in Python, and end up with an application that is written in three languages.<br /> <br /> If you rewrite, you end up with better code and you understand the code better.<br /> <br /> Similar to pair programming, one would invest some time in continuos rewriting, but there are benefits.<br /> <br /> == How? Theory ==<br /> <br /> (Insert slide.)<br /> <br /> If a piece of software (for example Factplace) has several components in one language with one architecture, single small components (for example, component A) could be rewritten in different ways or languages. The slide shows how component A is implemented in two different languages (A and A').<br /> <br /> (Jason promised to add two links here. One is http://backstage.soundcloud.com/2012/08/evolution-of-soundclouds-architecture/ )<br /> <br /> (Squirrel thinks the links are http://www.slideshare.net/mobile/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm and http://www.infoq.com/news/2013/05/dystopia-as-a-service .)<br /> <br /> == How? Practice ==<br /> <br /> The speaker showed Whooshingby web application that has a slider which determines how much Ruby or Python code the application uses.<br /> <br /> How to do it? Find some time every week, find a quiet piece of code (that is not changing a lot at the moment) and rewrite it.<br /> <br /> == Puzzle ==<br /> <br /> How to find opportunities (paid or open source) where he could exercise continuous rewriting.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_Rewriting&diff=15510 2013-09-28T15:35:30Z

<p>Douglassquirrel: /* How? Theory */</p> <hr /> <div>= Continuos Rewriting =<br /> <br /> CITCON Europe 2013 4:30-5:30 pm topic.<br /> <br /> == Why? ==<br /> <br /> Business people find smart people that write a lot of crappy code fast. The code does the job done, but it really needs to be rewritten. If you have read Joel Spolsky's blog post on how completely rewriting the code is really really (really) bad, then you know it is not what needs to be done.<br /> <br /> The speaker found himself several times in a situation to start working on a project that is in a &quot;needs rewrite desperately&quot; mode. What if we could rewrite continuously?<br /> <br /> Every week, even if the code is not broken, we rewrite a piece of code. After a while, all code base will be rewritten. We might not use the rewritten code. <br /> <br /> One has to invest a amount of time to do that.<br /> <br /> You can rewrite a piece of PHP application in Ruby, another piece in Python, and end up with an application that is written in three languages.<br /> <br /> If you rewrite, you end up with better code and you understand the code better.<br /> <br /> Similar to pair programming, one would invest some time in continuos rewriting, but there are benefits.<br /> <br /> == How? Theory ==<br /> <br /> (Insert slide.)<br /> <br /> If a piece of software (for example Factplace) has several components in one language with one architecture, single small components (for example, component A) could be rewritten in different ways or languages. The slide shows how component A is implemented in two different languages (A and A').<br /> <br /> (Jason promised to add two links here.)<br /> <br /> (Squirrel thinks the links are http://www.slideshare.net/mobile/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm and http://www.infoq.com/news/2013/05/dystopia-as-a-service .)<br /> <br /> == How? Practice ==<br /> <br /> The speaker showed Whooshingby web application that has a slider which determines how much Ruby or Python code the application uses.<br /> <br /> How to do it? Find some time every week, find a quiet piece of code (that is not changing a lot at the moment) and rewrite it.<br /> <br /> == Puzzle ==<br /> <br /> How to find opportunities (paid or open source) where he could exercise continuous rewriting.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=ContinuousDeploymentWithoutCI&diff=15484 2013-09-28T12:54:56Z

<p>Douglassquirrel: Created page with &quot;Secret sales does e-commerce. Cont. deployment 3-4 times a day, keep system running. Use Jenkins, but not do release to P. Some tests on the newly created code. Team does no...&quot;</p> <hr /> <div>Secret sales does e-commerce.<br /> <br /> Cont. deployment 3-4 times a day, keep system running. Use Jenkins, but not do release to P. Some tests on the newly created code.<br /> <br /> Team does not do TDD. Despite being a big ball of code. The code is not testable. Because recovering can be really fast, the urgency is not that high.<br /> <br /> It has 24/7 monitoring. Devs are on call. This helps on ensuring commitment from the devs. Hence monitoring is quite okay.<br /> <br /> A fellow developer does a code review.<br /> QA and product person check the application.<br /> <br /> Google Experiments is used to do A-B testing.<br /> <br /> PHP has some nice features, for one, each customer is running in it's own process.<br /> Capistrano is used to do release the code. It can do rollback. A couple of <br /> <br /> How about doing something similar on a Java platform. You can do Red/Green deployment.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=CITCONEurope2013Sessions&diff=15483 2013-09-28T12:54:25Z

<p>Douglassquirrel: /* 2:00 Topics */</p> <hr /> <div>CITCON Europe 2013 Turin Sessions<br /> <br /> Back to the [[Main Page]]<br /> <br /> == 10:00 Topics ==<br /> <br /> # [[Are we doing improvement wrong?]]<br /> # ---<br /> # ---<br /> # ---<br /> # ---<br /> <br /> == 11:15 Topics ==<br /> <br /> # <br /> # [[Continuous Delivery with Puppet - what is missing?]]<br /> # <br /> # <br /> #<br /> <br /> == Lunch Topics ==<br /> <br /> # ---<br /> <br /> == 2:00 Topics ==<br /> <br /> # [[ContinuousDeploymentWithoutCI]]<br /> # ---<br /> # <br /> # <br /> # ---<br /> <br /> == 3:15 Topics ==<br /> <br /> # <br /> # <br /> # ---<br /> # ---<br /> # <br /> <br /> == 4:30 Topics ==<br /> <br /> # <br /> # <br /> # ---<br /> # ---<br /> # ---<br /> <br /> <br /> ==Final session==<br /> [[CitconEurope2013: Ah-ha moments]]<br /> <br /> == Table View ==<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Room name<br /> ! 10:00<br /> ! 11:15<br /> ! 2:00<br /> ! 3:15<br /> ! 4:30<br /> |-<br /> | The Big Room<br /> | --- <br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> |-<br /> | Meeting One<br /> | --- <br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> |-<br /> | Library<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> |-<br /> | Meeting Two<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> |-<br /> | Garden<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> | ---<br /> |}</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15445 2013-09-26T05:23:27Z

<p>Douglassquirrel: </p> <hr /> <div>VP Engineering at Secretsales, a fast-growing online retailer.<br /> <br /> I have attended every CITCON in Europe:<br /> * I helped with the [[Continuous_rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am happy to provide free tech support for any of the tools I talked about in these sessions, particularly Hudson plugins. And yes, Secretsales is recruiting: http://secretsales.com/careers/<br /> <br /> Personal site: http://douglassquirrel.com<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Douglas_Squirrel&diff=15444 2013-09-26T05:22:49Z

<p>Douglassquirrel: </p> <hr /> <div>VP Engineering at Secretsales, a fast-growing online retailer.<br /> <br /> I have attended every CITCON in Europe:<br /> * I helped with the [[Continuous_Rewriting]] session at CITCON Budapest 2012.<br /> * I helped with the [[Root_Cause_Analysis]] and [[Dev_and_Ops_and_System_Ops_oh_my]] sessions at CITCON London 2011.<br /> * I helped with the [[Pairing_Techniques]] and [[Overcoming_Organisational_Defensiveness]] sessions at CITCON London 2010.<br /> * I helped with the [[HudsonAndOtherPlugins]] session at CITCON Paris 2009. <br /> * I helped with two sessions at CITCON Brussels 2007: [[Karma_For_Continuous_Integration]] and [[MutationTesting]]. <br /> * I attended CITCON London 2006 and CITCON Amsterdam 2008 but don't seem to have written anything up! Shame on me.<br /> <br /> I am happy to provide free tech support for any of the tools I talked about in these sessions, particularly Hudson plugins. And yes, Secretsales is recruiting: http://secretsales.com/careers/<br /> <br /> Personal site: http://douglassquirrel.com<br /> <br /> Email: ds at douglassquirrel dot com</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=15059 2013-02-07T06:04:23Z

<p>Douglassquirrel: /* Post-CITCON comments and ideas */</p> <hr /> <div>== Introduction ==<br /> <br /> What would happen if your team rewrote every line of code in your application every six months? <br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly<br /> <br /> == Post-CITCON comments and ideas ==<br /> <br /> [[Peter Zsoldos]] made several helpful comments after the conference; he asked <br /> * what role acceptance tests might play in a CR world (do we keep them or delete them on a rewrite? Squirrel thinks we keep them and modify as needed)<br /> * what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?<br /> Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?<br /> <br /> An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.<br /> <br /> [http://andypalmer.com/ Andy Palmer] drew comparisons with the [http://www.infoq.com/presentations/Micro-Services micro-services ideas] described by [http://www.linkedin.com/pub/james-lewis/2/4b/5b1 James Lewis] of Thoughtworks. Here are some [http://www.slideshare.net/jamesalewis/java-microservices slides on micro-services].<br /> <br /> [[Julian Gamble]] pointed to the [http://queue.acm.org/detail.cfm?id=1531242 continuous rewriting of a language] by [http://en.wikipedia.org/wiki/Arthur_Whitney_%28computer_scientist%29 Arthur Whitney].</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=15058 2013-02-07T06:00:34Z

<p>Douglassquirrel: /* Post-CITCON comments and ideas */</p> <hr /> <div>== Introduction ==<br /> <br /> What would happen if your team rewrote every line of code in your application every six months? <br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly<br /> <br /> == Post-CITCON comments and ideas ==<br /> <br /> [[Peter Zsoldos]] made several helpful comments after the conference; he asked <br /> * what role acceptance tests might play in a CR world (do we keep them or delete them on a rewrite? Squirrel thinks we keep them and modify as needed)<br /> * what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?<br /> Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?<br /> <br /> An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.<br /> <br /> [http://andypalmer.com/ Andy Palmer] drew comparisons with the [http://www.infoq.com/presentations/Micro-Services micro-services ideas] described by [http://www.linkedin.com/pub/james-lewis/2/4b/5b1 James Lewis] of Thoughtworks. Here are some [http://www.slideshare.net/jamesalewis/java-microservices slides on micro-services].</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=15057 2013-02-06T08:57:09Z

<p>Douglassquirrel: /* Post-CITCON comments and ideas */</p> <hr /> <div>== Introduction ==<br /> <br /> What would happen if your team rewrote every line of code in your application every six months? <br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly<br /> <br /> == Post-CITCON comments and ideas ==<br /> <br /> [[Peter Zsoldos]] made several helpful comments after the conference; he asked <br /> * what role acceptance tests might play in a CR world (do we keep them or delete them on a rewrite? Squirrel thinks we keep them and modify as needed)<br /> * what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?<br /> Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?<br /> <br /> An [http://blog.appfog.com/what-the-obama-it-team-teaches-us-about-polyglot-programming/ article on the Obama campaign's software] by [http://www.linkedin.com/pub/luc-perkins/22/7b3/a08 Luc Perkins] suggests that the Democrats used some of the techniques described here, such as combining many small components with a short half-life, though the article doesn't mention how much rewriting they did.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=15056 2013-02-06T08:48:34Z

<p>Douglassquirrel: </p> <hr /> <div>== Introduction ==<br /> <br /> What would happen if your team rewrote every line of code in your application every six months? <br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly<br /> <br /> == Post-CITCON comments and ideas ==<br /> <br /> [[Peter Zsoldos]] made several helpful comments after the conference; he asked <br /> * what role acceptance tests might play in a CR world (do we keep them or delete them on a rewrite? Squirrel thinks we keep them and modify as needed)<br /> * what might a CR advocate say to the points raised by Joel Spolsky in his [http://www.joelonsoftware.com/articles/fog0000000069.html article on rewrites]?<br /> Peter also wrote a [http://zsoldosp.blogspot.com/2013/01/continuous-team-switching.html blog post] addressing some of the issues raised in this session and raising a new question: how might CR help teams rotate developers more effectively?</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14953 2013-01-14T05:32:11Z

<p>Douglassquirrel: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> <br /> What would happen if your team rewrote every line of code in your application every six months? <br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14952 2013-01-14T05:31:07Z

<p>Douglassquirrel: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. Continuous Rewriting (CR) promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months? <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14947 2013-01-08T18:21:19Z

<p>Douglassquirrel: </p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;, which promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months? <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code<br /> <br /> == Characteristics ==<br /> <br /> We thought of these characteristics a system built using CR would likely have:<br /> * Made up of small components (e.g. source code under 10K bytes)<br /> * Components connected by messaging system<br /> * Reduced usage of database, perhaps no database at all<br /> * Deployment in stages - component live but isolated, then side-by-side with existing component, then fully deployed<br /> * Polyglot - components written in a wide variety of languages<br /> * Business metrics monitored, automated actions to address (similar to [http://timothyfitz.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/ IMVU's continuous delivery system], which automatically rolls back if revenue drops)<br /> * Team develop rewriting rules, goals, guidelines<br /> * Business receptive to new ideas, driven to change quickly</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14946 2013-01-08T18:05:59Z

<p>Douglassquirrel: </p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;, which promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months? <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?<br /> <br /> == Benefits ==<br /> <br /> We brainstormed these possible benefits of adopting CR:<br /> * Code evolves with business understanding<br /> * Eliminate code ownership<br /> * Fast feedback and fixes<br /> * Reduces team [http://en.wikipedia.org/wiki/Bus_factor bus number], i.e. more people know more of the code<br /> * Simpler, shorter code</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14945 2013-01-08T17:54:40Z

<p>Douglassquirrel: /* Techniques */</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;, which promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months? <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system checks whether they got the same result and takes appropriate action if they didn't. Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14811 2012-11-08T22:26:31Z

<p>Douglassquirrel: </p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;, which promises better responsiveness, faster feedback, improved understanding, and simpler code through regular rewriting of every part of a complex software product. For example, what would happen if your team ensured that every line of code in the application got replaced every six months? <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> The model is similar to [http://en.wikipedia.org/wiki/Spaced_learning spaced learning], where you repeat things you want to learn at intervals to help you retain them.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system that checks whether they got the same result and takes appropriate action if they didn't. (Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.<br /> <br /> == Problems and Questions ==<br /> <br /> We raised these questions and thought of these problems with Continuous Rewriting:<br /> <br /> Front-end, visual code could be a problem area; A-B testing could help.<br /> <br /> Infrequent events - e.g. an annual audit or quarterly report - could form roadblocks to a CR-using team, as they won't easily have the opportunity to check that the rewritten code gets the same result as the old code in production.<br /> <br /> A stack of unanswered questions:<br /> * What about infrastructure? Retrofitting to existing software? Organisational acceptance? (Fast feedback and fix may help with the latter.) <br /> * Are there types of application where this approach won't work?<br /> * Can you get the same learning benefits from team rotation?<br /> * Will increased readability for the rewriter mean better code, or will it mean less comprehension for others on the team?<br /> * Will CR-using teams have tacit code ownership or will CR eliminate that ownership?</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14810 2012-11-08T22:12:41Z

<p>Douglassquirrel: /* Introduction */</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;, which promises better responsiveness, faster feedback, improved understanding, and simpler code. <br /> <br /> The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system that checks whether they got the same result and takes appropriate action if they didn't. (Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14809 2012-11-08T22:09:34Z

<p>Douglassquirrel: /* Techniques */</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system that checks whether they got the same result and takes appropriate action if they didn't. (Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]<br /> <br /> [http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work LMAX Disruptor] and [http://martinfowler.com/eaaDev/EventSourcing.html Event Sourcing] are models that may be helpful for CR.</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14808 2012-11-08T22:05:49Z

<p>Douglassquirrel: /* Discussion */</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]<br /> <br /> Will CR scale as CI and CD appear to? Way too early to know, but Fred George at Forward has large teams using their &quot;programmer anarchy&quot; model.<br /> <br /> == Techniques ==<br /> <br /> We moved on to discuss methods that might be used by teams adopting Continuous Rewriting. These included:<br /> <br /> Dan North's &quot;Spike and Stabilise&quot; method, where you code something quickly, prove it is useful, then write tests that help you explore your code and stabilise it.<br /> <br /> Hot-swapping or simultaneous running of old and new code - for example, both old and new code draw the same work items from a common queue and a voting or filtering system that checks whether they got the same result and takes appropriate action if they didn't. (Related example: NASA put four computers in the Space Shuttle that voted on how to steer the ship:<br /> <br /> &quot;On the Shuttle, four identical AP-101Bs would function simultaneously as a quadruple-redundant set during critical mission phases such as ascent and reentry, processing the same information, derived from completely separate data buses, in precise synchronization. If a conflict arose among the four primary computers, the majority would rule, voting the conflicting unit out of the loop. None of the computers, singly or en masse, could turn off any other—that step was left to the crew. An errant machine would announce itself to the crew with warning lights, audio signals, and display-screen messages—all suggesting that the crew might want to isolate (i.e.; turn off) the offending computer from the system.&quot; - [http://history.nasa.gov/sts1/pages/computer.html NASA history]</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14807 2012-11-08T21:20:56Z

<p>Douglassquirrel: start of discussion</p> <hr /> <div>== Introduction ==<br /> <br /> Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. The session opened with discussion of the chart and two examples below:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}<br /> <br /> === Example 1: DRW ===<br /> <br /> * Small, expendable, co-operating components<br /> * Each fit for purpose<br /> * Hard shell, soft centre<br /> * Message = API<br /> * Identifiable boundaries for experiment<br /> <br /> References: [http://vimeo.com/43659070 Dan North talk], [http://qconlondon.com/dl/qcon-london-2012/slides/DanNorth_DecisionsDecisions.pdf Slides]<br /> <br /> === Example 2: Forward ===<br /> <br /> * Small, short-lived apps<br /> * No testing<br /> * Continuous deployment<br /> <br /> References: [http://forwardtechnology.co.uk/videos/32447325 Fred George talk], [http://www.slideshare.net/fredgeorge/programmer-anarchy-chinese Slides]<br /> <br /> == Discussion ==<br /> <br /> We discussed and criticised the thesis and examples. Points made included:<br /> <br /> Why does rewriting hurt? You may have crack devs who push for a rewrite, but the new code doesn't quite match the old, and the rewrite causes a delay, and the new code becomes legacy quickly. If you have slobs, they may just live with the old code which is equally bad.<br /> <br /> [http://www.red-gate.com Red Gate] use a strategy called &quot;continuous monitoring&quot;.<br /> <br /> Some strategies for piecemeal rewrites:<br /> * when you get a change request, extract the relevant component and rewrite it<br /> * the [http://www.martinfowler.com/bliki/StranglerApplication.html Strangler pattern]</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14806 2012-11-08T20:53:30Z

<p>Douglassquirrel: chart finished</p> <hr /> <div>Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. The session opened with discussion of this chart:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | <br /> | <br /> | ''Delivery hurts, so automate &amp; do more often.'' - one-click deploy, IMVU<br /> | Tools and culture! - DevOps, Puppet, Chef, Capistrano, Octopus<br /> | General adoption by advanced teams? - CD book<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | <br /> | <br /> | <br /> | ''Rewrites hurt, so automate &amp; do more often.'' - DRW (Dan North), Forward (Fred George)<br /> | ????<br /> |}</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=Continuous_rewriting&diff=14805 2012-11-08T20:49:19Z

<p>Douglassquirrel: first draft of chart</p> <hr /> <div>Squirrel presented for discussion the thesis that &quot;Continuous Rewriting&quot; is an emerging theme for software development, a successor to better-known ideas &quot;Continuous Integration&quot; and &quot;Continuous Deployment&quot;. The session opened with discussion of this chart:<br /> <br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! scope=&quot;col&quot;| <br /> ! scope=&quot;col&quot;| 2000-3<br /> ! scope=&quot;col&quot;| 2004-6<br /> ! scope=&quot;col&quot;| 2007-9<br /> ! scope=&quot;col&quot;| 2010-12<br /> ! scope=&quot;col&quot;| 2012-<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Integration<br /> | ''Integration hurts, so automate &amp; do more often.'' - Daily Builds, Ant, CruiseControl<br /> | More tools! - JetBrains, Hudson, BuildForge<br /> | Adopted by advanced teams - CI books, CITCON<br /> | Tool shakeout, standard for new teams - Jenkins<br /> | Adopted by late majority?<br /> |-<br /> ! scope=&quot;row&quot;| Continuous Deployment<br /> | foo<br /> | foo<br /> | foo<br /> | foo<br /> | foo<br /> |-<br /> ! scope=&quot;row&quot; | Continuous Rewriting<br /> | foo<br /> | foo<br /> | foo<br /> | foo<br /> | foo<br /> |}</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=TDD2012&diff=14703 2012-10-20T09:03:34Z

<p>Douglassquirrel: </p> <hr /> <div>[http://coderetreat.org Global Day of Code Retreat] 8th December 2012<br /> <br /> How deep to go in TDD?<br /> <br /> What do you mean by deep? Have to mock a lot, could have a million assertions<br /> <br /> [http://www.growing-object-oriented-software.com/ Growing Object Oriented Software, Guided by Tests]<br /> <br /> Pavel - TDD not suitable for prototyping<br /> <br /> Henk &amp; Jeffrey - works for them, aids in figuring out what code should do<br /> <br /> [http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html Clean Room development], Feathers - similar thinking about what your code should do but no tests<br /> <br /> Have to have a mock for everything not in this class -&gt; listening to code<br /> <br /> [http://www.exampler.com/old-blog/2003/08/21/ Testing Quadrant] - Brian Marick, classification of tests<br /> <br /> Jeffrey - earlier projects rescued by tests<br /> <br /> * One project's code was bad, acceptance tests correct, rescued by running ATs and fixing<br /> * Another project had good code in Java, porting to Ruby; ported tests first, then wrote code until tests passed, smooth process<br /> <br /> Can write tests only after initial design, when in &quot;bug-fix&quot; mode - Pavel<br /> <br /> Painful to retrofit tests - see [http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Working Effectively with Legacy Code, Feathers]<br /> <br /> Does writing tests make you think less hard? Lets you decouple and delay decision about implementation as you are focussing on output. Henk - makes me think more, consider design and API<br /> <br /> Do you use pairing? Not currently, feel I need someone at same experience level to go fast - PJ has a talk on pairing styles including how to work with differing skill levels<br /> <br /> Some people don't always write tests if few customers or code is for fun<br /> <br /> Jeffrey - experience writing fun code for robot wars competition, expectation about quality of code != actual quality, so always writes tests<br /> <br /> Do you find TDD lets you think less? Decouples and lets you delay implementation decision<br /> <br /> Henk - makes me think _more_ about design and API<br /> <br /> Jeffrey - maybe thinking hard but about _fewer things_<br /> <br /> PJ - Don't write production code without a failing test<br /> <br /> Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now)<br /> <br /> How about performance? Should run thousands of unit tests per second, but existing code may be too slow (Henk: reading file stream one byte at a time), need to revise<br /> <br /> Pavel - we do continuous delivery and find that you need to have tests for every change; don't deploy if this is missing<br /> <br /> How do you motivate yourself to do TDD? [http://www.butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata Screencast from Uncle Bob] and similar examples can be motivating<br /> <br /> Other examples: [http://www.jamesshore.com/Blog/Lets-Play/Episode-176.html Jeff Shore Let's Play TDD], [http://pairwith.us PairWithUs]<br /> <br /> Do brainteaser for every bug: how could I have written a test for this bug?<br /> <br /> Jeffrey - one dev wrote tests because he didn't trust colleagues, they broke his code and he could detect right away, eventually said &quot;how do you know? [CI &amp; tests] oh, we should all do that&quot;<br /> <br /> Pavel - wants to know about changes, continuous testing tells him about them<br /> <br /> Relative salary of dev &amp; testers can be a motive for testing<br /> <br /> Jeffrey - Scott Ambler discussing pairing with CTO, polled team, only 20% had code on screen &amp; looking at it, so pairing would double productivity<br /> <br /> These are not personal motivations;<br /> <br /> Personal motivations:<br /> <br /> * &quot;to be less wrong&quot;<br /> * not to be in debugger<br /> * not get stuck<br /> * Want not to be afraid of refactoring<br /> * want to change code with confidence<br /> * feel safer<br /> * avoid angry emails from customers<br /> * not find from &quot;git blame&quot; that the jerk who wrote the awful code was yourself<br /> * love experience of writing code for 4 hours, check in, works first time<br /> <br /> Jeffrey - at Agitar, didn't want generated tests for their own code (because of course it was fine) but to protect themselves against someone else breaking their code<br /> <br /> How do you convince others to adopt TDD?<br /> <br /> Jeffrey - Crossing the Chasm and what motivates change<br /> <br /> * Early adopters adopt TDD because it's better - only 15% of world<br /> * Later adopters have to have it solve a live problem for them<br /> <br /> Easy to &quot;make&quot; some teams use TDD, others harder, especially third parties, as they are not convinced - Jeffrey &quot;not a problem for them&quot;<br /> <br /> Coding dojo to practise better methods every couple of weeks, majority accept that this works, six months in most are still doing unit testing<br /> <br /> Squirrel - &quot;Convincing&quot; people wrong mindset, help team to solve problems that they observe<br /> <br /> Writing tests that pass is like sex - after you have it the first time you never look back</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=TDD2012&diff=14702 2012-10-20T09:01:00Z

<p>Douglassquirrel: </p> <hr /> <div>How deep to go in TDD?<br /> <br /> What do you mean by deep? Have to mock a lot, could have a million assertions<br /> <br /> [http://www.growing-object-oriented-software.com/ Growing Object Oriented Software, Guided by Tests]<br /> <br /> Pavel - TDD not suitable for prototyping<br /> <br /> Henk &amp; Jeffrey - works for them, aids in figuring out what code should do<br /> <br /> [http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html Clean Room development], Feathers - similar thinking about what your code should do but no tests<br /> <br /> Have to have a mock for everything not in this class -&gt; listening to code<br /> <br /> [http://www.exampler.com/old-blog/2003/08/21/ Testing Quadrant] - Brian Marick, classification of tests<br /> <br /> Jeffrey - earlier projects rescued by tests<br /> <br /> * One project's code was bad, acceptance tests correct, rescued by running ATs and fixing<br /> * Another project had good code in Java, porting to Ruby; ported tests first, then wrote code until tests passed, smooth process<br /> <br /> Can write tests only after initial design, when in &quot;bug-fix&quot; mode - Pavel<br /> <br /> Painful to retrofit tests - see [http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Working Effectively with Legacy Code, Feathers]<br /> <br /> Does writing tests make you think less hard? Lets you decouple and delay decision about implementation as you are focussing on output. Henk - makes me think more, consider design and API<br /> <br /> Do you use pairing? Not currently, feel I need someone at same experience level to go fast - PJ has a talk on pairing styles including how to work with differing skill levels<br /> <br /> Some people don't always write tests if few customers or code is for fun<br /> <br /> Jeffrey - experience writing fun code for robot wars competition, expectation about quality of code != actual quality, so always writes tests<br /> <br /> Do you find TDD lets you think less? Decouples and lets you delay implementation decision<br /> <br /> Henk - makes me think _more_ about design and API<br /> <br /> Jeffrey - maybe thinking hard but about _fewer things_<br /> <br /> PJ - Don't write production code without a failing test<br /> <br /> Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now)<br /> <br /> How about performance? Should run thousands of unit tests per second, but existing code may be too slow (Henk: reading file stream one byte at a time), need to revise<br /> <br /> Pavel - we do continuous delivery and find that you need to have tests for every change; don't deploy if this is missing<br /> <br /> How do you motivate yourself to do TDD? [http://www.butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata Screencast from Uncle Bob] and similar examples can be motivating<br /> <br /> Other examples: [http://www.jamesshore.com/Blog/Lets-Play/Episode-176.html Jeff Shore Let's Play TDD], [http://pairwith.us PairWithUs]<br /> <br /> Do brainteaser for every bug: how could I have written a test for this bug?<br /> <br /> Jeffrey - one dev wrote tests because he didn't trust colleagues, they broke his code and he could detect right away, eventually said &quot;how do you know? [CI &amp; tests] oh, we should all do that&quot;<br /> <br /> Pavel - wants to know about changes, continuous testing tells him about them<br /> <br /> Relative salary of dev &amp; testers can be a motive for testing<br /> <br /> Jeffrey - Scott Ambler discussing pairing with CTO, polled team, only 20% had code on screen &amp; looking at it, so pairing would double productivity<br /> <br /> These are not personal motivations;<br /> <br /> Personal motivations:<br /> <br /> * &quot;to be less wrong&quot;<br /> * not to be in debugger<br /> * not get stuck<br /> * Want not to be afraid of refactoring<br /> * want to change code with confidence<br /> * feel safer<br /> * avoid angry emails from customers<br /> * not find from &quot;git blame&quot; that the jerk who wrote the awful code was yourself<br /> * love experience of writing code for 4 hours, check in, works first time<br /> <br /> Jeffrey - at Agitar, didn't want generated tests for their own code (because of course it was fine) but to protect themselves against someone else breaking their code<br /> <br /> How do you convince others to adopt TDD?<br /> <br /> Jeffrey - Crossing the Chasm and what motivates change<br /> <br /> * Early adopters adopt TDD because it's better - only 15% of world<br /> * Later adopters have to have it solve a live problem for them<br /> <br /> Easy to &quot;make&quot; some teams use TDD, others harder, especially third parties, as they are not convinced - Jeffrey &quot;not a problem for them&quot;<br /> <br /> Coding dojo to practise better methods every couple of weeks, majority accept that this works, six months in most are still doing unit testing<br /> <br /> Squirrel - &quot;Convincing&quot; people wrong mindset, help team to solve problems that they observe<br /> <br /> Writing tests that pass is like sex - after you have it the first time you never look back</div>

Douglassquirrel https://citconf.com/wiki/index.php?title=TDD2012&diff=14701 2012-10-20T08:54:53Z

<p>Douglassquirrel: </p> <hr /> <div>How deep to go in TDD?<br /> <br /> What do you mean by deep? Have to mock a lot, could have a million assertions<br /> <br /> [http://www.growing-object-oriented-software.com/ Growing Object Oriented Software, Guided by Tests]<br /> <br /> Pavel - TDD not suitable for prototyping<br /> <br /> Henk &amp; Jeffrey - works for them, aids in figuring out what code should do<br /> <br /> [http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html Clean Room development], Feathers - similar thinking about what your code should do but no tests<br /> <br /> Have to have a mock for everything not in this class -&gt; listening to code<br /> <br /> [http://www.exampler.com/old-blog/2003/08/21/ Testing Quadrant] - Brian Marick, classification of tests<br /> <br /> Jeffrey - earlier projects rescued by tests<br /> <br /> * One project's code was bad, acceptance tests correct, rescued by running ATs and fixing<br /> * Another project had good code in Java, porting to Ruby; ported tests first, then wrote code until tests passed, smooth process<br /> <br /> Can write tests only after initial design, when in &quot;bug-fix&quot; mode - Pavel<br /> <br /> Painful to retrofit tests - see [http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Working Effectively with Legacy Code, Feathers]<br /> <br /> Does writing tests make you think less hard? Lets you decouple and delay decision about implementation as you are focussing on output. Henk - makes me think more, consider design and API<br /> <br /> Do you use pairing? Not currently, feel I need someone at same experience level to go fast - PJ has a talk on pairing styles including how to work with differing skill levels<br /> <br /> Some people don't always write tests if few customers or code is for fun<br /> <br /> Jeffrey - experience writing fun code for robot wars competition, expectation about quality of code != actual quality, so always writes tests<br /> <br /> Do you find TDD lets you think less? Decouples and lets you delay implementation decision<br /> <br /> Henk - makes me think _more_ about design and API<br /> <br /> Jeffrey - maybe thinking hard but about _fewer things_<br /> <br /> PJ - Don't write production code without a failing test<br /> <br /> Jeffrey - Pair partner is both conscience (did you write a test?) and gives you permission (OK not to figure that out now)<br /> <br /> How about performance? Should run thousands of unit tests per second, but existing code may be too slow (Henk: reading file stream one byte at a time), need to revise<br /> <br /> Pavel - we do continuous delivery and find that you need to have tests for every change; don't deploy if this is missing<br /> <br /> How do you motivate yourself to do TDD? [http://www.butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata Screencast from Uncle Bob] and similar examples can be motivating<br /> <br /> Other examples: [http://www.jamesshore.com/Blog/Lets-Play/Episode-176.html Jeff Shore Let's Play TDD], [http://pairwith.us PairWithUs]<br /> <br /> Do brainteaser for every bug: how could I have written a test for this bug?<br /> <br /> Jeffrey - one dev wrote tests because he didn't trust colleagues, they broke his code and he could detect right away, eventually said &quot;how do you know? [CI &amp; tests] oh, we should all do that&quot;<br /> <br /> Pavel - wants to know about changes, continuous testing tells him about them<br /> <br /> Relative salary of dev &amp; testers can be a motive for testing<br /> <br /> Jeffrey - Scott Ambler discussing pairing with CTO, polled team, only 20% had code on screen &amp; looking at it, so pairing would double productivity<br /> <br /> These are not personal motivations;<br /> <br /> Personal motivations:<br /> <br /> * &quot;to be less wrong&quot;<br /> * not to be in debugger<br /> * not get stuck<br /> * Want not to be afraid of refactoring<br /> * want to change code with confidence<br /> * feel safer<br /> * avoid angry emails from customers<br /> * not find from &quot;git blame&quot; that the jerk who wrote the awful code was yourself<br /> * love experience of writing code for 4 hours, check in, works first time<br /> <br /> Jeffrey - at Agitar, didn't want generated tests for their own code (because of course it was fine) but to protect themselves against someone else breaking their code<br /> <br /> How do you convince others to adopt TDD?<br /> <br /> Jeffrey - Crossing the Chasm and what motivates change<br /> <br /> * Early adopters adopt TDD because it's better - only 15% of world<br /> * Later adopters have to have it solve a live problem for them</div>

Douglassquirrel