Loading ...
Sorry, an error occurred while loading the content.

Physical System Analogy

Expand Messages
  • Arrizza, John
    Conceptually I view X analgous to a physical system, e.g. a solar system, where every element in that system is pulling or pushing on every other element
    Message 1 of 25 , Jun 28, 2001
    • 0 Attachment
      Conceptually I view X analgous to a physical system, e.g. a solar system,
      where every element in that system is "pulling" or "pushing" on every other
      element in the system either directly or indirectly.

      If I remove or alter one element of that system, say Mars, the dynamics of
      the entire system change and therefore the final revised system
      configuration is nearly unpredictable. If the Pull or Push forces are very
      high, the dynamics are much more "explosive": a tiny local change causes a
      drastic overall change.

      Elements directly connected to each other are more affected by a change to
      one of its partner elements or to the inclusion of a new element. Elements
      indirectly connected to each other are less affected because they are more
      "distant".

      If an element is complicated or large or central, it is more "massive".
      Alterations to massive elements cause higher reverberations through out the
      system.

      Is this a valid conceptual model of a software system?

      Refactoring in this view reduces the forces between elements. It does this
      by:

      - reducing the mass of individual elements
      - reducing the overall number of elements
      - reducing the number of direct partners of any particular element
      - increases distances between elements

      Unit Tests in this view are ?

      John
    • Phlip
      ... This is called a Dynamic Attractor . For example, if a water fountain with a controller that sets it to a given pressure, that pressure setting will
      Message 2 of 25 , Jun 28, 2001
      • 0 Attachment
        Proclaimed Arrizza, John from the mountaintops:

        > Conceptually I view X analgous to a physical system, e.g. a solar
        > system, where every element in that system is "pulling" or "pushing" on
        > every other element in the system either directly or indirectly.

        This is called a "Dynamic Attractor". For example, if a water fountain
        with a controller that sets it to a given pressure, that pressure setting
        will "attract" the height of the water column to a given distance.

        Darwinian Evolution is a dynamic attractor between a gene-pool and the
        niche it lives in. Change the niche, the attracting node moves, and the
        gene-pool follows it (or dies out).

        > If I remove or alter one element of that system, say Mars, the dynamics
        > of the entire system change and therefore the final revised system
        > configuration is nearly unpredictable. If the Pull or Push forces are
        > very high, the dynamics are much more "explosive": a tiny local change
        > causes a drastic overall change.

        This represents a system changing from a single attractor to more than one
        unstable attractors. That makes a system sensitive to initial conditions
        because a single attractor would have just dampened them out.

        > Elements directly connected to each other are more affected by a change
        > to one of its partner elements or to the inclusion of a new element.
        > Elements indirectly connected to each other are less affected because
        > they are more "distant".
        >
        > If an element is complicated or large or central, it is more "massive".
        > Alterations to massive elements cause higher reverberations through out
        > the system.
        >
        > Is this a valid conceptual model of a software system?

        It's a valid conceptual model of Evolution. XP deigns to be an "emergent
        system" whereby a number of simple rules, applied as if mindlessly by
        distributed agents (programmers) produces emergent behavior that evolves
        code. So yes; the concept of attractors is well studied & worth a look
        here.

        >
        > Refactoring in this view reduces the forces between elements. It does
        > this by:
        >
        > - reducing the mass of individual elements
        > - reducing the overall number of elements
        > - reducing the number of direct partners of any particular element
        > - increases distances between elements
        >
        > Unit Tests in this view are ?

        In small scale terms, UTs are the nodes attracting the behavior of the
        source code. Refactoring to fix the above smells makes source easier to
        submit to that attraction.

        --
        Phlip phlip_cpp@...
        ============== http://phlip.webjump.com ==============
        -- MCCD - Microsoft Certified Co-Dependent --
      • Hugo Garcia
        Hi Too mechanistic and causal of an analysis. How about if you base your analysis upon probalistic terms with the quantifiable as the probability of an event
        Message 3 of 25 , Jun 29, 2001
        • 0 Attachment
          Hi

          Too mechanistic and causal of an analysis. How about
          if you base your analysis upon probalistic terms with
          the quantifiable as the probability of an event
          ocurring, not ocurring, maybe ocurring or maybe not
          occurring. Conceptually the quantifiable can be
          regarded as a measure of risk, change, progress (take
          your pick).

          Now due to the more than prevalent Newtonian
          visualization of reality we tend to concentrate our
          attention on the objects involved rather than on
          events that occur in our reality. By event I mean a
          valid description of some change in the system which
          is bounded by time and space that exposes the
          relationship within objects of the system. It is
          therefore the relationship that is quantified not the
          object per se.

          In OO (the current system to which we would like to
          allude) the relationships are our famous associations
          and messages that we send between objects. When we
          code we construct and deconstruct (refactoring)the
          messages (relationships) of our program (system).
          Quantifying risk could involve the action measuring
          how many unit test we have. From a qualitative point
          we could say that the more unit tests I have the less
          risk in the system and therefore the probrability of
          events coalescing into the big crash becomes less.

          Still a casual description but by measuring the
          probrabilities of events you avoid the mechanistic
          view of things.

          -H



          --- "Arrizza, John" <john.arrizza@...> wrote:
          > Conceptually I view X analgous to a physical system,
          > e.g. a solar system,
          > where every element in that system is "pulling" or
          > "pushing" on every other
          > element in the system either directly or indirectly.
          >
          >
          > If I remove or alter one element of that system, say
          > Mars, the dynamics of
          > the entire system change and therefore the final
          > revised system
          > configuration is nearly unpredictable. If the Pull
          > or Push forces are very
          > high, the dynamics are much more "explosive": a tiny
          > local change causes a
          > drastic overall change.
          >
          > Elements directly connected to each other are more
          > affected by a change to
          > one of its partner elements or to the inclusion of a
          > new element. Elements
          > indirectly connected to each other are less affected
          > because they are more
          > "distant".
          >
          > If an element is complicated or large or central, it
          > is more "massive".
          > Alterations to massive elements cause higher
          > reverberations through out the
          > system.
          >
          > Is this a valid conceptual model of a software
          > system?
          >
          > Refactoring in this view reduces the forces between
          > elements. It does this
          > by:
          >
          > - reducing the mass of individual elements
          > - reducing the overall number of elements
          > - reducing the number of direct partners of any
          > particular element
          > - increases distances between elements
          >
          > Unit Tests in this view are ?
          >
          > John
          >
          >
          >
          >
          > To Post a message, send it to:
          > extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > Don't miss XP UNIVERSE, the first US conference on
          > XP and Agile Methods. see www.xpuniverse.com for
          > details and registration.
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Get personalized email addresses from Yahoo! Mail
          http://personal.mail.yahoo.com/



          [Non-text portions of this message have been removed]
        • Arrizza, John
          ... Could the attractors theory could be put into practice for software? For example: - statically analyse the code for elements, and the coupling between them
          Message 4 of 25 , Jun 29, 2001
          • 0 Attachment
            > -----Original Message-----
            > From: Phlip [mailto:pplumlee@...]
            > So yes; the concept of attractors is well studied &
            > worth a look here.

            Could the attractors theory could be put into practice for software? For
            example:

            - statically analyse the code for elements, and the coupling between them
            - assign a mass to each element based on some set of characteristics in the
            code
            - assign distances between elements similarily
            - run the system collecting data correlating them back to the individual
            elements
            - analyse the resulting data stream

            Would the analysis be useful?!
            John
          • Phlip
            ... Unsure if any experiments are underway in that regard among professionally marketed methodologies... ... Build time. Next? ... Graphs. ... Directed
            Message 5 of 25 , Jun 29, 2001
            • 0 Attachment
              Proclaimed Arrizza, John from the mountaintops:
              > > -----Original Message-----
              > > From: Phlip [mailto:pplumlee@...]

              > > So yes; the concept of attractors is well studied &
              > > worth a look here.
              >
              > Could the attractors theory could be put into practice for software?

              Unsure if any experiments are underway in that regard among professionally
              marketed methodologies...

              > For example:
              >
              > - statically analyse the code for elements, and the coupling between
              > them - assign a mass to each element based on some set of
              > characteristics in the code

              Build time. Next?

              > - assign distances between elements similarily

              Graphs.

              > - run the system collecting data correlating them back to the individual
              > elements

              Directed weighted closed simple & simplicial graphs. Minimizing build &
              test times. We sense faultage in the directions this pulls from the
              attracting nodes. Idioms & icons crumble.

              > - analyse the resulting data stream

              That's worth 60 k or so of features. No idea if the bid's low or high
              generally...

              --
              Phlip phlip_cpp@...
              ============== http://phlip.webjump.com ==============
              -- This machine last rebooted during the Second Millenium --
            • Ron Jeffries
              ... Compared to just reading the perfectly clear code containing no duplication and a test for each feature? Hmmm ... Ronald E Jeffries
              Message 6 of 25 , Jun 29, 2001
              • 0 Attachment
                Responding to Arrizza, John (11:26 AM 6/29/2001 -0400):
                >Could the attractors theory could be put into practice for software? For
                >example:
                >
                >- statically analyse the code for elements, and the coupling between them
                >- assign a mass to each element based on some set of characteristics in the
                >code
                >- assign distances between elements similarily
                >- run the system collecting data correlating them back to the individual
                >elements
                >- analyse the resulting data stream
                >
                >Would the analysis be useful?!

                Compared to just reading the perfectly clear code containing no duplication
                and a test for each feature? Hmmm ...



                Ronald E Jeffries
                http://www.XProgramming.com
                http://www.objectmentor.com
              • Baker, Bram
                For XP, no, but perhaps such an analysis might be helpful for dealing with big ol legacy systems. It may help you get some idea about the structure of the
                Message 7 of 25 , Jun 29, 2001
                • 0 Attachment
                  For XP, no, but perhaps such an analysis might be helpful for dealing with
                  big ol legacy systems. It may help you get some idea about the structure of
                  the application, e.g. maybe knowing which bits are the "massive" ones would
                  help in assessing the impact of change.

                  On the other hand, there's nothing like diving in and changing things as a
                  means to assessing the impact of said changes.

                  Bram Baker

                  -----Original Message-----
                  From: Ron Jeffries [mailto:ronjeffries@...]
                  Sent: Friday, June 29, 2001 3:37 PM
                  To: extremeprogramming@yahoogroups.com
                  Subject: RE: [XP] Physical System Analogy


                  Responding to Arrizza, John (11:26 AM 6/29/2001 -0400):
                  >Could the attractors theory could be put into practice for software? For
                  >example:
                  >
                  >- statically analyse the code for elements, and the coupling between them
                  >- assign a mass to each element based on some set of characteristics in the
                  >code
                  >- assign distances between elements similarily
                  >- run the system collecting data correlating them back to the individual
                  >elements
                  >- analyse the resulting data stream
                  >
                  >Would the analysis be useful?!

                  Compared to just reading the perfectly clear code containing no duplication
                  and a test for each feature? Hmmm ...



                  Ronald E Jeffries
                  http://www.XProgramming.com
                  http://www.objectmentor.com

                  To Post a message, send it to: extremeprogramming@...

                  To Unsubscribe, send a blank message to:
                  extremeprogramming-unsubscribe@...

                  Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods.
                  see www.xpuniverse.com for details and registration.

                  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



                  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                  This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

                  Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.


                  ==============================================================================


                  [Non-text portions of this message have been removed]
                • Arrizza, John
                  ... You re right but the situation I was thinking of was: - the code is legacy - the effort to convert from its current state to perfectly clear code, etc. is
                  Message 8 of 25 , Jul 2, 2001
                  • 0 Attachment
                    > -----Original Message-----
                    > From: Ron Jeffries [mailto:ronjeffries@...]
                    > Compared to just reading the perfectly clear code containing
                    > no duplication and a test for each feature? Hmmm ...
                    You're right but the situation I was thinking of was:
                    - the code is legacy
                    - the effort to convert from its current state to perfectly clear code,
                    etc. is very high.
                    (These assumptions are not too far out of reality are they? Such code exists
                    right?)

                    Imagine a run-time analysis tool that gave good prescriptive information on
                    where the app was "bad", to guide you to the best classes to begin
                    converting to perfectly clear code, etc. Would that be useful?
                  • Ron Jeffries
                    ... Tools can definitely be useful. The Refactoring Browser, for example, has a lint for Smalltalk. I m not sure why it would be a run-time tool to detect
                    Message 9 of 25 , Jul 2, 2001
                    • 0 Attachment
                      Responding to Arrizza, John (10:17 AM 7/2/2001 -0400):
                      > > -----Original Message-----
                      > > From: Ron Jeffries [mailto:ronjeffries@...]
                      > > Compared to just reading the perfectly clear code containing
                      > > no duplication and a test for each feature? Hmmm ...
                      >You're right but the situation I was thinking of was:
                      > - the code is legacy
                      > - the effort to convert from its current state to perfectly clear code,
                      >etc. is very high.
                      >(These assumptions are not too far out of reality are they? Such code exists
                      >right?)
                      >
                      >Imagine a run-time analysis tool that gave good prescriptive information on
                      >where the app was "bad", to guide you to the best classes to begin
                      >converting to perfectly clear code, etc. Would that be useful?

                      Tools can definitely be useful. The Refactoring Browser, for example, has a
                      "lint" for Smalltalk.

                      I'm not sure why it would be a run-time tool to detect unclear code,
                      however. Can you clear that up for me?


                      Ronald E Jeffries
                      http://www.XProgramming.com
                      http://www.objectmentor.com
                    • nevin@smalltalk.org
                      ... example, has a ... code, ... So, Ron, is that a vote FOR or AGAINST SmallLint? Or, are you saying that you don t think SmallLint is a run-time tool for
                      Message 10 of 25 , Jul 2, 2001
                      • 0 Attachment
                        --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                        > Responding to Arrizza, John (10:17 AM 7/2/2001 -0400):
                        > > > -----Original Message-----
                        > > > From: Ron Jeffries [mailto:ronjeffries@a...]
                        >
                        > Tools can definitely be useful. The Refactoring Browser, for
                        example, has a
                        > "lint" for Smalltalk.
                        >
                        > I'm not sure why it would be a run-time tool to detect unclear
                        code,
                        > however. Can you clear that up for me?
                        >
                        >
                        > Ronald E Jeffries
                        > http://www.XProgramming.com
                        > http://www.objectmentor.com

                        So, Ron, is that a vote FOR or AGAINST SmallLint? Or, are you saying
                        that you don't think SmallLint is a run-time tool for detecting
                        unclear code?

                        I'm confused.

                        Nevin
                      • Arrizza, John
                        ... Run-time because the context in which complex parts of the code show themselves best occurs at run-time. I may be mistaken but I believe that static
                        Message 11 of 25 , Jul 2, 2001
                        • 0 Attachment
                          > -----Original Message-----
                          > From: Ron Jeffries [mailto:ronjeffries@...]
                          > I'm not sure why it would be a run-time tool to detect unclear code,
                          > however. Can you clear that up for me?
                          :)

                          Run-time because the context in which complex parts of the code show
                          themselves best occurs at run-time. I may be mistaken but I believe that
                          static analysis tools (such as Lint) depend on there being a strong
                          correlation between what the source "looks like" and what actually occurs at
                          run-time. In most cases there *is* a strong correlation between the two.
                          Some tools go so far as to simulate running parts of the code to ensure the
                          correlation is there.

                          But in many cases, the correlation just isn't there. The example that comes
                          to mind is multi-threaded code. It can look trivial statically but can have
                          a much more complicated run-time "footprint". (that apparent simplicity, I
                          think, leads people to not spend time looking at it, and that explains the
                          prevalence of race conditions.)

                          In the absence of run-time analysis tools, what can be used to find the
                          hotspots in an application? To determine that statically there would need to
                          be a theory that correlates source code to bug location and consequently bug
                          frequency. The best correlation that I know of for bug frequency is LOC. If
                          that were true, refactoring a legacy app should be a simple matter of
                          finding the methods/functions with the largest number of lines and
                          refactoring those mercilessly.

                          I've tried that. My experience is that refactoring in a shotgun pattern
                          works and it doesn't work: the app gets "better" but I didn't always get to
                          the parts of the code that had the core problems.

                          The shotgun approach also works only if the app is small. Otherwise there's
                          just too much "space" between the refactored pieces of code to have a
                          significant effect on the app overall.

                          Just my $.02,
                          John
                        • Michael Schneider
                          John, We use several axis of data to determine where refactoring dollars are spent. Note: you use different function/per axis depending on what your business
                          Message 12 of 25 , Jul 2, 2001
                          • 0 Attachment
                            John,

                            We use several axis of data to determine where refactoring dollars
                            are spent. Note: you use different function/per axis depending
                            on what your business goals are for the current release.

                            (FYI, we use data gathering tools because of the size of our code
                            base >10Mil LOC :-{

                            Here are the Axis that we are working with:

                            1) Design Goals of Architecture - what do you want your architecture to look like


                            2) Actual Design of Architecture - What is the current structure
                            (static model)

                            3) Binary Dependency Structure - who calls who, how many times, (hot spot
                            from a link dependency)

                            4) Compile Dependency Structure - To compile file X, how much of the world
                            to I have to compile

                            5) Run Time Path Data - We run system tests against the code to find out which
                            areas are exercised when user scenarios are executed


                            Example Analysis from 5-Axis Data Model

                            You are chartered to refactor subsystem XYZ, and develop the module so that
                            you can swap out algorithms. This subsystem is ~750,000 LOC, how do you
                            start? Answer, gather the data for each axis defined above, here are the results:

                            Data from axis 1) is where you would like to end up (nice component system)

                            Data from axis 2) shows that you have no interface classes in subsystem XYX,

                            Data from axis 3) indicates that the API to subsystem XYZ is being ignored,
                            and that people are calling directly into implementation functions

                            Data from axis 4) reinforces the no interface class data from axis 2), The result of this
                            is that the whole world must be recompiled when a concrete implementation is
                            changed.


                            Where do you start ?

                            Step 1: Set Priorities:
                            - You don't want to bring down the system while you are working
                            - You have a rich set of test cases for the existing algorithms, so
                            this guides you to refactoring the form first, then function
                            - Since you are doing form first, find 3-5 algorithms that will be swapped
                            in and out for the new-plugable XYX subsystem
                            - Spike the framework for these Algs to get a handle on what the API will
                            need to be.
                            - Use the data from axis 3) to find out who the customers are of subsystem
                            XYZ, and determine what functions are used, and create a histogram of the
                            number of times each function is called
                            - Use the data from axis 5) to determine which functions are called by user scenarios, and create a histogram to find the hot
                            functions
                            - Revisit your API with this data to make sure that the "Hot" functions are
                            cheap to call
                            - Define your API, Implement interface classes, realize interface functionality
                            with existing functionality
                            - modify calling routines to use your api
                            - run test suite


                            Congratulations!!!!!!!!!!!!! you now have a subsystem that is independent of
                            the rest of the system, except through your interface API layer, you will need
                            to enter new rules for axis 1) to define allowed dependencies for you system.
                            Anyone that bypasses the API will now be flagged as a design violation
                            in axis 2).

                            Now refactor away and have fun

                            ----------------------------------------------------
                            How to pick areas to focus on?

                            Refactoring selections takes two approaches for us:

                            - How much are we spending today in each subsystem (defect tracking
                            against code)
                            - What areas of the architecture will be impacted the most by the projects
                            for the next release.

                            That data allows a business decision to be made on which systems get
                            refactoring effort.




                            Have fun, and hope this helps,
                            Mike



                            "Arrizza, John" wrote:

                            > > -----Original Message-----
                            > > From: Ron Jeffries [mailto:ronjeffries@...]
                            > > I'm not sure why it would be a run-time tool to detect unclear code,
                            > > however. Can you clear that up for me?
                            > :)
                            >
                            > Run-time because the context in which complex parts of the code show
                            > themselves best occurs at run-time. I may be mistaken but I believe that
                            > static analysis tools (such as Lint) depend on there being a strong
                            > correlation between what the source "looks like" and what actually occurs at
                            > run-time. In most cases there *is* a strong correlation between the two.
                            > Some tools go so far as to simulate running parts of the code to ensure the
                            > correlation is there.
                            >
                            > But in many cases, the correlation just isn't there. The example that comes
                            > to mind is multi-threaded code. It can look trivial statically but can have
                            > a much more complicated run-time "footprint". (that apparent simplicity, I
                            > think, leads people to not spend time looking at it, and that explains the
                            > prevalence of race conditions.)
                            >
                            > In the absence of run-time analysis tools, what can be used to find the
                            > hotspots in an application? To determine that statically there would need to
                            > be a theory that correlates source code to bug location and consequently bug
                            > frequency. The best correlation that I know of for bug frequency is LOC. If
                            > that were true, refactoring a legacy app should be a simple matter of
                            > finding the methods/functions with the largest number of lines and
                            > refactoring those mercilessly.
                            >
                            > I've tried that. My experience is that refactoring in a shotgun pattern
                            > works and it doesn't work: the app gets "better" but I didn't always get to
                            > the parts of the code that had the core problems.
                            >
                            > The shotgun approach also works only if the app is small. Otherwise there's
                            > just too much "space" between the refactored pieces of code to have a
                            > significant effect on the app overall.
                            >
                            > Just my $.02,
                            > John
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                            >
                            > Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods. see www.xpuniverse.com for details and registration.
                            >
                            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                          • Ron Jeffries
                            ... I like SmallLint. And it is not a run-time tool because it lints your program while your program is not running. A profiler would be a run-time tool, as it
                            Message 13 of 25 , Jul 2, 2001
                            • 0 Attachment
                              Responding to nevin@... (02:50 PM 7/2/2001 +0000):
                              >So, Ron, is that a vote FOR or AGAINST SmallLint? Or, are you saying
                              >that you don't think SmallLint is a run-time tool for detecting
                              >unclear code?
                              >
                              >I'm confused.

                              I like SmallLint. And it is not a run-time tool because it lints your
                              program while your program is not running. A profiler would be a run-time
                              tool, as it analyzes the performance of my program as it runs. Lint (the
                              original) runs on the source. SmallLint runs by reflection, but my program
                              is not executing when SmallLint analyzes it.

                              Does that make sense?



                              Ronald E Jeffries
                              http://www.XProgramming.com
                              http://www.objectmentor.com
                            • Ron Jeffries
                              ... It sure seems in your report that you must be doing refactoring in very big chunks: you actually _schedule_ it. What might happen if you refactored all the
                              Message 14 of 25 , Jul 2, 2001
                              • 0 Attachment
                                Responding to Michael Schneider (02:22 PM 7/2/2001 -0400):

                                >We use several axis of data to determine where refactoring dollars
                                >are spent. Note: you use different function/per axis depending
                                >on what your business goals are for the current release.

                                It sure seems in your report that you must be doing refactoring in very big
                                chunks: you actually _schedule_ it.

                                What might happen if you refactored all the time instead?

                                Ronald E Jeffries
                                http://www.XProgramming.com
                                http://www.objectmentor.com
                              • nevin@smalltalk.org
                                ... saying ... your ... run-time ... (the ... program ... Ah, yes. You are right of course. The image approach used by Smalltalk often makes me forget this
                                Message 15 of 25 , Jul 2, 2001
                                • 0 Attachment
                                  --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                                  > Responding to nevin@s... (02:50 PM 7/2/2001 +0000):
                                  > >So, Ron, is that a vote FOR or AGAINST SmallLint? Or, are you
                                  saying
                                  > >that you don't think SmallLint is a run-time tool for detecting
                                  > >unclear code?
                                  > >
                                  > >I'm confused.
                                  >
                                  > I like SmallLint. And it is not a run-time tool because it lints
                                  your
                                  > program while your program is not running. A profiler would be a
                                  run-time
                                  > tool, as it analyzes the performance of my program as it runs. Lint
                                  (the
                                  > original) runs on the source. SmallLint runs by reflection, but my
                                  program
                                  > is not executing when SmallLint analyzes it.
                                  >
                                  > Does that make sense?

                                  Ah, yes. You are right of course. The image approach used by
                                  Smalltalk often makes me forget this distinction. But you are right--
                                  the new code introduced into the image is not exercised by SmallLint.

                                  Nevin
                                • Michael Schneider
                                  ... Ron, Very good question, I will do my best to answer it. Our code base has evolved over the last 20 years, it all tended to be developed with the best
                                  Message 16 of 25 , Jul 2, 2001
                                  • 0 Attachment
                                    Ron Jeffries wrote:

                                    > Responding to Michael Schneider (02:22 PM 7/2/2001 -0400):
                                    >
                                    > >We use several axis of data to determine where refactoring dollars
                                    > >are spent. Note: you use different function/per axis depending
                                    > >on what your business goals are for the current release.
                                    >
                                    > It sure seems in your report that you must be doing refactoring in very big
                                    > chunks: you actually _schedule_ it.
                                    >
                                    > What might happen if you refactored all the time instead?

                                    Ron,

                                    Very good question, I will do my best to answer it.

                                    Our code base has evolved over the last 20 years, it all tended to be
                                    developed with the "best practice" of the day. Some areas are very
                                    cheap to maintain, so they don't appear on the cost radar for architecture.
                                    These portions of the code are mature feature wise, so you probably won't
                                    go into them for new projects.

                                    Other areas have a maintenance cost, but there is no new added functionality
                                    to go there, so that would be a candidate for a scheduled refactor.
                                    The maintenance resource model is high 'nuf to put together a hit squad
                                    for a couple of weeks, to do some refactoring. Again the reason for the
                                    scheduling is that the functionality is mature, it is the maintenance cost
                                    that drives it, not new functionality.

                                    S.W.A.G Warning!!!!!!!!!!!!!!!!!!

                                    If the data indicates that the team would spend more then 40-60% of their
                                    time refactoring the old system, rather than adding new functionality,
                                    then it may be a scheduled refactor (really swagging here :-{ )

                                    Other refactoring goes with new projects, this is not scheduled as a separate task,
                                    developers are in that code, so they can clean up things that get in their way.

                                    In project mode, refactoring is always a possibility at any time. The 5 axis
                                    give people a set of data points to help do estimation at the beginning of a project.

                                    The axis data is also useful to get metrics to justify 10 people refactoring
                                    for a major portion of the project.

                                    Again a VERY rough metric is that we try to keep legacy system refactoring
                                    below 40-60% for a scheduled project, it just wacks the velocity too much to be able to predict outcome for the new features.

                                    Not much of a science on that call, just a tradeoff between fixed release date, and
                                    fixed resource.

                                    One very important point, it is much harder to justify a refactoring project that
                                    a new functionality project, so it is very import to refactor as part of your
                                    project. I would not hope to be able to schedule a refactor for the project
                                    that I am working on this release, it is imperative to do it right the first time.


                                    I wish that I could give you more that S.W.A.G's but that is about all that I have
                                    right now,
                                    Mike


                                    >
                                    >
                                    > Ronald E Jeffries
                                    > http://www.XProgramming.com
                                    > http://www.objectmentor.com
                                    >
                                    > To Post a message, send it to: extremeprogramming@...
                                    >
                                    > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                    >
                                    > Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods. see www.xpuniverse.com for details and registration.
                                    >
                                    > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  • Arrizza, John
                                    ... model) ... Using a coverage tool I assume. How did you come up with the axes?
                                    Message 17 of 25 , Jul 2, 2001
                                    • 0 Attachment
                                      > -----Original Message-----
                                      > From: Michael Schneider [mailto:michael.schneider@...]
                                      > Here are the Axis that we are working with:
                                      >
                                      > 1) Design Goals of Architecture - what do you want your
                                      > architecture to look like
                                      >
                                      > 2) Actual Design of Architecture - What is the current structure (static
                                      model)
                                      >
                                      > 3) Binary Dependency Structure - who calls who, how many
                                      > times, (hot spot from a link dependency)
                                      >
                                      > 4) Compile Dependency Structure - To compile file X, how much
                                      > of the world to I have to compile
                                      >
                                      > 5) Run Time Path Data - We run system tests against the code
                                      > to find out which areas are exercised when user scenarios are executed
                                      Using a coverage tool I assume.

                                      How did you come up with the axes?
                                    • Arrizza, John
                                      ... Is there a correlation between probabilities of events and the locality of defects or of complex code?
                                      Message 18 of 25 , Jul 2, 2001
                                      • 0 Attachment
                                        > -----Original Message-----
                                        > From: Hugo Garcia [mailto:xpjava@...]
                                        > Still a casual description but by measuring the
                                        > probrabilities of events you avoid the mechanistic
                                        > view of things.

                                        Is there a correlation between probabilities of events and the locality of
                                        defects or of complex code?
                                      • Michael Schneider
                                        ... Axis 1) Is the architecture design, It is basically a UML Diagram with tools to enforce package dependency. Robert Martin from Object Mentor helped us
                                        Message 19 of 25 , Jul 2, 2001
                                        • 0 Attachment
                                          "Arrizza, John" wrote:

                                          > > -----Original Message-----
                                          > > From: Michael Schneider [mailto:michael.schneider@...]
                                          > > Here are the Axis that we are working with:
                                          > >
                                          > > 1) Design Goals of Architecture - what do you want your
                                          > > architecture to look like
                                          > >
                                          > > 2) Actual Design of Architecture - What is the current structure (static
                                          > model)
                                          > >
                                          > > 3) Binary Dependency Structure - who calls who, how many
                                          > > times, (hot spot from a link dependency)
                                          > >
                                          > > 4) Compile Dependency Structure - To compile file X, how much
                                          > > of the world to I have to compile
                                          > >
                                          > > 5) Run Time Path Data - We run system tests against the code
                                          > > to find out which areas are exercised when user scenarios are executed
                                          > Using a coverage tool I assume.
                                          >
                                          > How did you come up with the axes?

                                          Axis 1) Is the architecture design, It is basically a UML Diagram with tools to
                                          enforce package dependency. Robert Martin from Object Mentor helped us
                                          with the techniques for Axis 1)

                                          Axis 2) This axis came from the impact of our legacy system on the new design,
                                          we would come up with great designs for Axis 1, but when you came to realize
                                          them in the context of the system, you were challenged. Axis 2 was a short cut
                                          to allows have everybody that knew how that old system "really-worked"
                                          in one room. By automating this, and visualizing it, the architecture could
                                          review the "as-is" and say Whoah There!!!, that is not quite right. It is the
                                          big picture tool of the architecture

                                          Axis 3) This was gleaned from the exe's and the library archives, it was the
                                          call tree, for each exe

                                          Axis 4) came from #include info, our tools group has been gather this info for
                                          ~8 years, we just had to mine what they already had, source navigator is
                                          a nice Free tool to get this kind of information

                                          Axis 5) This came from our system test data, this is data contributed by customers,
                                          and defects over time. This also has beta test ...... This is to try to get as close to a
                                          "customer-oriented" view as possible.

                                          The data from the 5 axis are relatively easy to get, the hard part was visualization,
                                          and axis relationships. graphVis and java3d can help with this.

                                          This approach seems to hold up, it is the relationship between the axis that
                                          we are working on most now.

                                          It is just 5 different meta-models of the architecture, no one is perfect, but
                                          together, they can give you good info on the state of your system.

                                          Don't rely on it to heavily though, it just give you approximate state
                                          of the system. Number can lull you into a false sense of security,
                                          or a false panic.

                                          Hope this helps,
                                          Mike


                                          >
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                          >
                                          > Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods. see www.xpuniverse.com for details and registration.
                                          >
                                          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                        • Arrizza, John
                                          ... Actually, I meant why those axes and not some other set? John
                                          Message 20 of 25 , Jul 2, 2001
                                          • 0 Attachment
                                            > -----Original Message-----
                                            > From: Michael Schneider [mailto:michael.schneider@...]
                                            > > How did you come up with the axes?
                                            >
                                            > Axis 1) Is the architecture design, It is basically a UML
                                            <snip>

                                            Actually, I meant why those axes and not some other set?
                                            John
                                          • Ron Jeffries
                                            ... The word legacy would have answered my question simply but without deep understanding of what you do. Your detailed remarks are very helpful. Thanks!
                                            Message 21 of 25 , Jul 2, 2001
                                            • 0 Attachment
                                              Responding to Michael Schneider (03:37 PM 7/2/2001 -0400):

                                              >Very good question, I will do my best to answer it.
                                              >
                                              >Our code base has evolved over the last 20 years ...

                                              The word "legacy" would have answered my question simply but without deep
                                              understanding of what you do. Your detailed remarks are very helpful. Thanks!



                                              Ronald E Jeffries
                                              http://www.XProgramming.com
                                              http://www.objectmentor.com
                                            • Michael Schneider
                                              John, Those were developed over time to meet business/technical needs. We looked at the problems that we were facing, looked at the work others were doing,
                                              Message 22 of 25 , Jul 2, 2001
                                              • 0 Attachment
                                                John,

                                                Those were developed over time to meet business/technical needs.
                                                We looked at the problems that we were facing, looked at the work
                                                others were doing, then tried several things over time.

                                                We picked axis that had some overlap, but gave a look at the architecture
                                                from a different view. The overlap allowed relationships to be established,
                                                the differences allowed views that were not possible without the
                                                axis.

                                                You may be able to get similar info from different axis, this set seems
                                                to work well for us so far. Next year it may be the 7 axis, or we may
                                                figured out how to merge 2 into 1 and then it would be the 4 axis.

                                                With the relationships that we have now, it takes 5.

                                                Hope this helps,
                                                Mike



                                                "Arrizza, John" wrote:

                                                > > -----Original Message-----
                                                > > From: Michael Schneider [mailto:michael.schneider@...]
                                                > > > How did you come up with the axes?
                                                > >
                                                > > Axis 1) Is the architecture design, It is basically a UML
                                                > <snip>
                                                >
                                                > Actually, I meant why those axes and not some other set?
                                                > John
                                                >
                                                > To Post a message, send it to: extremeprogramming@...
                                                >
                                                > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                                >
                                                > Don't miss XP UNIVERSE, the first US conference on XP and Agile Methods. see www.xpuniverse.com for details and registration.
                                                >
                                                > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                              • Hugo Garcia
                                                Hmmmmm...... Good question. I will have to ponder for a while. -H ... __________________________________________________ Do You Yahoo!? Get personalized email
                                                Message 23 of 25 , Jul 2, 2001
                                                • 0 Attachment
                                                  Hmmmmm......

                                                  Good question. I will have to ponder for a while.

                                                  -H



                                                  --- "Arrizza, John" <john.arrizza@...> wrote:
                                                  > > -----Original Message-----
                                                  > > From: Hugo Garcia [mailto:xpjava@...]
                                                  > > Still a casual description but by measuring the
                                                  > > probrabilities of events you avoid the mechanistic
                                                  > > view of things.
                                                  >
                                                  > Is there a correlation between probabilities of
                                                  > events and the locality of
                                                  > defects or of complex code?
                                                  >
                                                  > To Post a message, send it to:
                                                  > extremeprogramming@...
                                                  >
                                                  > To Unsubscribe, send a blank message to:
                                                  > extremeprogramming-unsubscribe@...
                                                  >
                                                  > Don't miss XP UNIVERSE, the first US conference on
                                                  > XP and Agile Methods. see www.xpuniverse.com for
                                                  > details and registration.
                                                  >
                                                  > Your use of Yahoo! Groups is subject to
                                                  > http://docs.yahoo.com/info/terms/
                                                  >
                                                  >


                                                  __________________________________________________
                                                  Do You Yahoo!?
                                                  Get personalized email addresses from Yahoo! Mail
                                                  http://personal.mail.yahoo.com/



                                                  [Non-text portions of this message have been removed]
                                                • Arrizza, John
                                                  ... I couldn t help but notice the similarity of the axes you chose to Lakos s recommendations in Large Scale C++ Development.
                                                  Message 24 of 25 , Jul 3, 2001
                                                  • 0 Attachment
                                                    > -----Original Message-----
                                                    > From: Michael Schneider [mailto:michael.schneider@...]
                                                    > Those were developed over time to meet business/technical needs.

                                                    I couldn't help but notice the similarity of the axes you chose to Lakos's
                                                    recommendations in Large Scale C++ Development.
                                                  • Arrizza, John
                                                    ... Just a thought: If the probability of an event is high then the likelihood of a defect is low. In other words, if an event occurs a lot then defects, if
                                                    Message 25 of 25 , Jul 6, 2001
                                                    • 0 Attachment
                                                      > -----Original Message-----
                                                      > From: Hugo Garcia [mailto:xpjava@...]
                                                      > Good question. I will have to ponder for a while.
                                                      > --- "Arrizza, John" <john.arrizza@...> wrote:
                                                      > > > -----Original Message-----
                                                      > > > From: Hugo Garcia [mailto:xpjava@...]
                                                      > > > Still a casual description but by measuring the
                                                      > > > probrabilities of events you avoid the mechanistic
                                                      > > > view of things.
                                                      > >
                                                      > > Is there a correlation between probabilities of
                                                      > > events and the locality of defects or of complex code?

                                                      Just a thought: If the probability of an event is high then the likelihood
                                                      of a defect is low. In other words, if an event occurs a lot then defects,
                                                      if any, will manifest themselves more often therefore they tend to get
                                                      fixed. (This also seems to jive with my experience.)

                                                      In a sense, this is one of the reasons behind Unit Testing. It causes events
                                                      to occur with (almost) even probability.

                                                      back to legacy systems:
                                                      On first blush, this implies that the first Unit Tests should be written for
                                                      the least used code. But perhaps there is low-use code and then there is
                                                      low-use code. An example of the latter is dead code. No point in unit
                                                      testing that. Ditto but less so for code that implements low priority/low
                                                      use features.

                                                      So what's left? Code that implements high-use features but is invoked "once
                                                      in a while".

                                                      And that implies this snippet:
                                                      1) Identify and remove all dead code by running a line coverage tool while
                                                      running the system over all features.
                                                      2) Identify code implementing high-use features by running a line coverage
                                                      tool while those features are run.
                                                      3) Write Unit Tests for the remaining code in all of the classes identified
                                                      in step1.

                                                      let me know what you think...
                                                      John
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.