JayFlowers

Bodhisattva in Training

August 29, 2007 Continuous Integration

Loop Diagrams

Jeffery Fredrick asked for some verbage around the loop diagrams that are in the slides from this post.

The first slide with a loop diagram was about simply adding value:

AddValueLoop

This is generally the situation in which a project is in before adding Continuous Integration.  Please know that the Ss and Os in the diagram stand for same and opposite (thanks again Jeff), meaning the two nodes connected by the line vary the same or in opposition.  So this diagram says that:  As desired value increases so does the gap in value.  As the gap in value increase so does the actions to add value.  When there is a delay in the system or when the perception is inadequate, increases in action to add value worsen the delay and or perception, which in turn increase the gap in value.  Alternatively when the system does not have a delay or issue with fidelity of perception, actual value increases as actions to add value increase, which decrease the gap in value.

I like the picture better than my words. 🙂

 

The next slide is on causality:

CropperCapture[14]

I first blogged about this back in this post.  I really like this example.  I think it does a spectacular job of taking what is normally very tacit knowledge and makes it accessible to your cerebral cortex.  This is a concrete example of the previous diagram and hopefully is an easy step from there to here.

The next slide is on the question: Did what we just change make things worse?

CropperCapture[2]

What is this stuff about mind you say?  I originally blog about this over here.  Here is the excerpt:

…Many new practitioners of meditation say that there minds are more chaotic and less calm than before they ever meditated.  Their instructor will point out that this is a perception.  That this is a good sign.  Their minds are not more chaotic, they are more aware of their minds.  They have reduced a delay in feedback as well as increased the quality of the feedback.

This perception of things getting worse before they get better is common to any system in which there is:

  • A negative gap in reality and the perception of reality.
  • A significant delay in perception.
  • Poor quality of perception.

Many Agile practices fall into this category.  They not only remove delays, they increase the fidelity of the feedback.

Ignorance is bliss?  At least until the bill is due.

The last loop diagram slide is on specifically CI of course. 😛

CILoopDiagram

This diagram is by no means complete.  It is meant to spark a dialogue on this subject.  I would like it to to be a resource for people who are evaluating possible changes to their environment or even just to understand what is going on in there existing environment.  For example, it will help to answer the question: What are the consequences of a long running build?

I have a page on my wiki about working with this loop diagram here.  It includes information on understanding loop diagrams, creating loop diagrams, software for creating loop diagrams, as well as fodder and variables for this loop diagram.  Lastly it includes a link to a download of the project file for this loop diagram.

I hope over the next year to be able to flesh this out at all the different conferences that I will be going to.  I truly believe that this will be a great asset to the CI community.

3 to “Loop Diagrams”

Trackbacks/Pingbacks

  1. […] And to continue with the benefits of continuous integration, Jay Flowers has been doing some systems thinking. In Loop Diagrams he presents a series of models showing the effects of delayed feedback, finishing with a seriously complex model of effects related to build frequency. Jay points out that this is just the beginning: “This diagram is by no means complete. It is meant to spark a dialogue on this subject. I would like it to to be a resource for people who are evaluating possible changes to their environment or even just to understand what is going on in there existing environment.” I’ve found myself using systems models like these more and more frequently in recent months, and I believe our industry has a lot to gain from modelling and visualising the complex feedback systems inherent in our working environments; so I will be watching the development of Jay’s models with great interest… […]

  2. […] I was recently asked about breaking up the build by having a build hierarchy that mirrored the product’s package dependency tree.  I have seen this done, and done it myself, in a very coarse way, dividing along lines strongly marked both by organization and architecture.  There is a even a well known pattern on this: Named Stable Bases.  It should be made clear that this is a form of deferred integration.  Yes, yes, the ill consequences of deferred integration are the very things that continuous integration is working to alleviate.  Just because deferred integration has been abused in the past is no good reason not to wield it wisely now.  So lets take a look at how it alters the dynamics of a build system.  To show this I have created a loop diagram, see this post for more details on loop diagrams and remember that the “s” means varies the same and “o” means varies the opposite. […]

  3. […] I was recently asked about breaking up the build by having a build hierarchy that mirrored the product’s package dependency tree. I have seen this done, and done it myself, in a very coarse way, dividing along lines strongly marked both by organization and architecture. There is a even a well known pattern on this: Named Stable Bases. It should be made clear that this is a form of deferred integration. Yes, yes, the ill consequences of deferred integration are the very things that continuous integration is working to alleviate. Just because deferred integration has been abused in the past is no good reason not to wield it wisely now. So lets take a look at how it alters the dynamics of a build system. To show this I have created a loop diagram, see this post for more details on loop diagrams and remember that the "s" means varies the same and "o" means varies the opposite. […]

  1. carnival of the agilists, 6-sep-07 « silk and spinach says...

    […] And to continue with the benefits of continuous integration, Jay Flowers has been doing some systems thinking. In Loop Diagrams he presents a series of models showing the effects of delayed feedback, finishing with a seriously complex model of effects related to build frequency. Jay points out that this is just the beginning: “This diagram is by no means complete. It is meant to spark a dialogue on this subject. I would like it to to be a resource for people who are evaluating possible changes to their environment or even just to understand what is going on in there existing environment.” I’ve found myself using systems models like these more and more frequently in recent months, and I believe our industry has a lot to gain from modelling and visualising the complex feedback systems inherent in our working environments; so I will be watching the development of Jay’s models with great interest… […]

  2. JayFlowers > Consequences of Pipeline Structure says...

    […] I was recently asked about breaking up the build by having a build hierarchy that mirrored the product’s package dependency tree.  I have seen this done, and done it myself, in a very coarse way, dividing along lines strongly marked both by organization and architecture.  There is a even a well known pattern on this: Named Stable Bases.  It should be made clear that this is a form of deferred integration.  Yes, yes, the ill consequences of deferred integration are the very things that continuous integration is working to alleviate.  Just because deferred integration has been abused in the past is no good reason not to wield it wisely now.  So lets take a look at how it alters the dynamics of a build system.  To show this I have created a loop diagram, see this post for more details on loop diagrams and remember that the “s” means varies the same and “o” means varies the opposite. […]

  3. Test Early » Consequences of Pipeline Structure says...

    […] I was recently asked about breaking up the build by having a build hierarchy that mirrored the product’s package dependency tree. I have seen this done, and done it myself, in a very coarse way, dividing along lines strongly marked both by organization and architecture. There is a even a well known pattern on this: Named Stable Bases. It should be made clear that this is a form of deferred integration. Yes, yes, the ill consequences of deferred integration are the very things that continuous integration is working to alleviate. Just because deferred integration has been abused in the past is no good reason not to wield it wisely now. So lets take a look at how it alters the dynamics of a build system. To show this I have created a loop diagram, see this post for more details on loop diagrams and remember that the "s" means varies the same and "o" means varies the opposite. […]

Leave a Reply to carnival of the agilists, 6-sep-07 « silk and spinach Cancel reply