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

Re: Crossing the Developer-Data Divide

Expand Messages
  • deddy205ar
    Scott - ... Huh? Why do does the Agile community need to work with legacy systems? Isn t Agile moving so fast & light footed that legacy systems
    Message 1 of 27 , Jan 21, 2010
      Scott -
      >
      >   Bottom line is that we could be doing better, particularly agile teams
      > which don't appear to be working with existing legacy databases as
      > often as they should. 
      >

      Huh?

      Why do does the Agile community need to work with <gag, choke>
      legacy systems?

      Isn't Agile moving so fast & light footed that legacy systems are just a
      distant memory in the rear-view mirror?

      - David
    • Curt Sampson
      ... Because people still keep building the darn things. (At one point, I thought that the motto of my software company should have been, Building tomorrows
      Message 2 of 27 , Jan 22, 2010
        On 2010-01-22 04:05 -0000 (Fri), deddy205ar wrote:

        > Why do does the Agile community need to work with <gag, choke>
        > legacy systems?

        Because people still keep building the darn things.

        (At one point, I thought that the motto of my software company should have
        been, "Building tomorrows legacy systems today!")

        cjs
        --
        Curt Sampson <cjs@...> +81 90 7737 2974
        http://www.starling-software.com
        The power of accurate observation is commonly called cynicism
        by those who have not got it. --George Bernard Shaw
      • Markus Gallagher
        doesn t a system become legacy as soon as you write the first line of code? ... [Non-text portions of this message have been removed]
        Message 3 of 27 , Jan 24, 2010
          doesn't a system become "legacy" as soon as you write the first line of
          code?

          On Sat, Jan 23, 2010 at 5:19 AM, Curt Sampson <cjs@...>wrote:

          >
          >
          > On 2010-01-22 04:05 -0000 (Fri), deddy205ar wrote:
          >
          > > Why do does the Agile community need to work with <gag, choke>
          > > legacy systems?
          >
          > Because people still keep building the darn things.
          >
          > (At one point, I thought that the motto of my software company should have
          > been, "Building tomorrows legacy systems today!")
          >
          >
          > cjs
          > --
          > Curt Sampson <cjs@... <cjs%40cynic.net>> +81 90 7737 2974
          > http://www.starling-software.com
          > The power of accurate observation is commonly called cynicism
          > by those who have not got it. --George Bernard Shaw
          >
          >


          [Non-text portions of this message have been removed]
        • deddy205ar
          Markus - ... I d certainly be willing to argue that legacy is indeed the first line of working, depended on code. Once upon a time I worked in a shop where
          Message 4 of 27 , Jan 24, 2010
            Markus -

            >
            > doesn't a system become "legacy" as soon as you write the first line of
            > code?
            >

            I'd certainly be willing to argue that "legacy" is indeed the first line of
            working, depended on code.




            Once upon a time I worked in a shop where they emphasized how they
            were a DEVELOPMENT rather than MAINTENANCE shop.

            Turns out the definition was highly subjective... when a project was
            under two weeks, it was maintenance. More than two weeks was
            development.

            Obviously in the jargon of the time, development was good and
            maintenance was bad.

            Not quite sure how these attitudes map to Agile/Waterfall these days.

            - David
          • Scott Ambler
            No.  It becomes legacy once you ve deployed it. You re in maintenance mode as soon as you ve written a line of code. - Scott Scott W. Ambler Chief
            Message 5 of 27 , Feb 3, 2010
              No.  It becomes legacy once you've deployed it.

              You're in maintenance mode as soon as you've written a line of code.

              - Scott Scott W. Ambler
              Chief Methodologist/Agile, IBM Rational
              Agile at Scale blog: http://www.ibm.com/developerworks/blogs/page/ambler
              Follow me on Twitter: http://twitter.com/scottwambler



              ----- Original Message ----
              From: Markus Gallagher <markus.gallagher@...>
              To: agileDatabases@yahoogroups.com
              Sent: Sun, January 24, 2010 5:39:02 AM
              Subject: Re: [agileDatabases] Re: Crossing the Developer-Data Divide

              doesn't a system become "legacy" as soon as you write the first line of
              code?

              On Sat, Jan 23, 2010 at 5:19 AM, Curt Sampson <cjs@...>wrote:

              >
              >
              > On 2010-01-22 04:05 -0000 (Fri), deddy205ar wrote:
              >
              > > Why do does the Agile community need to work with <gag, choke>
              > > legacy systems?
              >
              > Because people still keep building the darn things.
              >
              > (At one point, I thought that the motto of my software company should have
              > been, "Building tomorrows legacy systems today!")
              >
              >
              > cjs
              > --
              > Curt Sampson <cjs@... <cjs%40cynic.net>> +81 90 7737 2974
              > http://www.starling-software.com
              > The power of accurate observation is commonly called cynicism
              > by those who have not got it. --George Bernard Shaw

              >


              [Non-text portions of this message have been removed]



              ------------------------------------

              Yahoo! Groups Links




              __________________________________________________________________
              Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
              http://ca.toolbar.yahoo.com
            • Curt Sampson
              ... Wow. So Agile really does produce legacy systems faster! :-) cjs -- Curt Sampson +81 90 7737 2974
              Message 6 of 27 , Feb 3, 2010
                On 2010-02-03 13:04 -0800 (Wed), Scott Ambler wrote:

                > No.  It becomes legacy once you've deployed it.

                Wow. So Agile really does produce legacy systems faster! :-)

                cjs
                --
                Curt Sampson <cjs@...> +81 90 7737 2974
                http://www.starling-software.com
                The power of accurate observation is commonly called cynicism
                by those who have not got it. --George Bernard Shaw
              • Markus Gallagher
                ... agree, but since we like short iterations in an agile project (preferably 2 weeks) it s legacy early on in the life cycle of the application ;) ...
                Message 7 of 27 , Feb 3, 2010
                  On Wed, Feb 3, 2010 at 10:04 PM, Scott Ambler <scottwambler@...>wrote:

                  >
                  >
                  > No. It becomes legacy once you've deployed it.
                  >
                  agree, but since we like short iterations in an agile project (preferably 2
                  weeks) it's legacy early on in the life cycle of the application ;)


                  >
                  > You're in maintenance mode as soon as you've written a line of code.
                  >


                  [Non-text portions of this message have been removed]
                • Willem Bogaerts
                  ... Which you could read as it becomes legacy as soon as you have written your first line of code . In practice, there are just more levels of legacy. For
                  Message 8 of 27 , Feb 4, 2010
                    > No. It becomes legacy once you've deployed it.
                    >
                    > You're in maintenance mode as soon as you've written a line of code.


                    Which you could read as "it becomes legacy as soon as you have written
                    your first line of code".

                    In practice, there are just more levels of legacy. For instance, my SQL
                    scripts "fix" the database to the currently needed state. Daily. Hourly,
                    even. Before I commit the source, the master SQL script should cause the
                    right database state to exist, even for existing databases. And that is
                    why it is legacy.

                    But those existing databases do not necessarily exist on the customer's
                    server. My fellow programmers also have there local sandbox databases
                    and they too are "fixed" by my script. Off course, being my fellow
                    programmers, they fix my fixing script as well.

                    Some of those fixes are not optimally legible. Especially when stored
                    procedures are needed, that can distract the reader from what the script
                    actually tries to accomplish. So when we deliver to the customer, we
                    roll up the changes. Off course, delivering to the customer is a good
                    opportunity to do some extra testing first, and that means all the team
                    members should get their project state updated. For instance, a new
                    table may have had some column changes during development of the
                    feature, but the delivery script only needs to create the table with the
                    final set of columns. So the procedure handling the column changes is
                    removed as it is no longer needed.

                    That is why I say there are more levels of legacy: legacy to your
                    colleagues, legacy to the customer, and even legacy to your customer's
                    customers if your customer sells a service that other people connect to.

                    All in all, it does not matter. Working with legacy code is what
                    programming is about. Especially with databases, if it were only for the
                    fact that a database is a central thing to be used by more than one
                    client. Agile programming is not merely building software, it is
                    morphing it. That is what I like about refactoring, for instance. I have
                    more the feeling that I am a sculptor than that I am putting the nuts
                    and bolts together. That also reflects the mindset. If you are a
                    nuts-and-bolts guy, all the nuts and bolts should be there, layed out in
                    a legible pattern before building and you have to know them all. A
                    sculptor works on the first essence and refines as he goes along. A
                    sculptor's way of thinking is more relaxed, as a sculptor fixes any
                    inconvenience. A builder does not.

                    (As a side note, I see now why I am so bad at drawing pictures. I
                    started my career as a technical designer (drawing metal structures) and
                    that is how I draw pictures. I never learned to even see the essence of
                    a picture without seeing the completed picture itself. But I digress.)

                    The building vs. sculpting way of thinking is also why I consider
                    programming a craft. We are not conveyor belt workers that add the same
                    feature to a standard product all day long. We are adding different
                    features and have to take the product into account. We fix the product
                    into accepting the new feature instead of just adding it. It is really
                    what programmers (should) do, whether they call themselves agile or not.
                    I mean, this is also what you get at the end of the waterfall. The main
                    difference with agile methods is that you love it and anticipate on it
                    instead of hating "destroying what you just built". A sculptor does not
                    hate morphing a feature, because he does not see it as destruction. It
                    is growth. It is organic. Like some cells in an embryo will die before
                    the organism is born. That is not destruction. These cells had their
                    purpose and lived to fulfil it.

                    Too bad most software projects are still managed as conveyor belt
                    projects instead of crafts. Agile methods try to change that, but my
                    experience is that that is the hardest part of introducing agile
                    methods. Even if your boss goes along with it, customers are not used to it.

                    Phew, it seems like I had to vent something. Sorry to have taken too
                    much of your time.

                    Have fun,
                    Willem Bogaerts.
                  • thetabetapi@ymail.com
                    The tone of this conversation is that agile is somehow a badge of quality in its own right and that anything produced before is instantly inferior. I can
                    Message 9 of 27 , Feb 4, 2010
                      The tone of this conversation is that agile is somehow a badge of quality in its own right and that anything produced before is instantly inferior.

                      I can remember discussing BS5750 with someone and their take on it was that it was that you could comply with it if you were consistent in your approach. In fact they opined that what BS5750 did was tell the world that you could (and probably did) produce crap to a consistent standard.

                      For me Agile is about delivering something closely aligned to the business needs when those needs can change dramatically in a short time-frame. Agile processes should have inherent safeguards that make poor coding less likely but there is no guarantee. The nature of Agile is such that (hopefully) you can clean it up anything nasty before it becomes too obvious that the underlying quality is a bit lacking.

                      High system quality and systems meeting the business need are not one and the same thing.
                    • acchecco
                      I whole-heartedly agree. I find Agile/Lean to be a mindset as much as a methodology. But any tool, even Agile, can be used to create poor results. Much like
                      Message 10 of 27 , Feb 7, 2010
                        I whole-heartedly agree. I find Agile/Lean to be a mindset as much as a methodology. But any tool, even Agile, can be used to create poor results. Much like any dogma, those who would think that -merely- following a set of rules will produce a quality product are misguided. I have lived through an organization's transition from a dogmatic waterfall environment, to a dogmatic Agile environment, and finally to a true understanding of the underlying Agile/Lean principles.

                        A few observations:
                        1 - No set of rules can replace quality communication with the customer.
                        2 - Rigidly following rules is for people who can't think for themselves.
                        3 - Any product must provide business value in a reasonable time, and
                        technical quality to withstand the test of time.
                      • Josue Barbosa dos Santos
                        I like the definition of Michael Feathers to legacy code: code without tests. From here
                        Message 11 of 27 , Feb 7, 2010
                          I like the definition of Michael Feathers to legacy code: code without
                          tests. From here
                          http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf:

                          ".... The main thing that distinguishes legacy code from non-legacy code is
                          tests, or rather a
                          lack of tests. We can get a sense of this with a little thought experiment:
                          how easy would
                          it be to modify your code base if it could bite back, if it could tell you
                          when you made a
                          mistake? It would be pretty easy, wouldn't it? Most of the fear involved
                          in making
                          changes to large code bases is fear of introducing subtle bugs; fear of
                          changing things
                          inadvertently. With tests, you can make things better with impunity. To
                          me, the
                          difference is so critical, it overwhelms any other distinction. With tests,
                          you can make
                          things better. Without them, you just don�t know whether things are getting
                          better or
                          worse..."

                          Of course it can be a bit simplistic. For example in the book Growing Object
                          Oriented Software - Guided by Tests, Nat Pryce says that had a system that
                          he created using tests. But when the client asked him (many months later) to
                          add more things, he says it was harder than expected because the tests was
                          not so expressive as it could be. He was testing methods, not behavior (1).

                          To summarize, in general I agree with Michael Feathers.

                          Abra�os,

                          Josu�.

                          PS - Sorry my English

                          (1) - I am writting this from memory. If there is something wrong with this
                          information, please forgive.


                          On Wed, Feb 3, 2010 at 6:04 PM, Scott Ambler <scottwambler@...> wrote:

                          >
                          >
                          > No. It becomes legacy once you've deployed it.
                          >
                          > You're in maintenance mode as soon as you've written a line of code.
                          >
                          >
                          > - Scott Scott W. Ambler
                          > Chief Methodologist/Agile, IBM Rational
                          > Agile at Scale blog: http://www.ibm.com/developerworks/blogs/page/ambler
                          > Follow me on Twitter: http://twitter.com/scottwambler
                          >
                          > ----- Original Message ----
                          > From: Markus Gallagher <markus.gallagher@...<markus.gallagher%40gmail.com>
                          > >
                          > To: agileDatabases@yahoogroups.com <agileDatabases%40yahoogroups.com>
                          > Sent: Sun, January 24, 2010 5:39:02 AM
                          > Subject: Re: [agileDatabases] Re: Crossing the Developer-Data Divide
                          >
                          > doesn't a system become "legacy" as soon as you write the first line of
                          > code?
                          >
                          > On Sat, Jan 23, 2010 at 5:19 AM, Curt Sampson <cjs@...<cjs%40starling-software.com>
                          > >wrote:
                          >
                          > >
                          > >
                          > > On 2010-01-22 04:05 -0000 (Fri), deddy205ar wrote:
                          > >
                          > > > Why do does the Agile community need to work with <gag, choke>
                          > > > legacy systems?
                          > >
                          > > Because people still keep building the darn things.
                          > >
                          > > (At one point, I thought that the motto of my software company should
                          > have
                          > > been, "Building tomorrows legacy systems today!")
                          > >
                          > >
                          > > cjs
                          > > --
                          > > Curt Sampson <cjs@... <cjs%40cynic.net> <cjs%40cynic.net>> +81 90
                          > 7737 2974
                          > > http://www.starling-software.com
                          > > The power of accurate observation is commonly called cynicism
                          > > by those who have not got it. --George Bernard Shaw
                          > >
                          > >
                          >
                          > [Non-text portions of this message have been removed]
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          > __________________________________________________________
                          > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
                          > favourite sites. Download it now
                          > http://ca.toolbar.yahoo.com
                          >
                          >
                          >



                          --
                          Abra�os,
                          Josu�
                          http://twitter.com/josuesantos


                          [Non-text portions of this message have been removed]
                        Your message has been successfully submitted and would be delivered to recipients shortly.