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

Re: [agileDatabases] Re: Crossing the Developer-Data Divide

Expand Messages
  • 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 1 of 27 , Feb 3, 2010
    • 0 Attachment
      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 2 of 27 , Feb 3, 2010
      • 0 Attachment
        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 3 of 27 , Feb 3, 2010
        • 0 Attachment
          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 4 of 27 , Feb 4, 2010
          • 0 Attachment
            > 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 5 of 27 , Feb 4, 2010
            • 0 Attachment
              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 6 of 27 , Feb 7, 2010
              • 0 Attachment
                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 7 of 27 , Feb 7, 2010
                • 0 Attachment
                  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.