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

Re: [XP] Re: fix or rewrite?

Expand Messages
  • Andy Glew
    ... Beware of Second System Syndrome . In the rewrite, the programmer is tempted to do things the right way, add features, create extensibility, etc. It is
    Message 1 of 20 , Apr 3, 2000
    • 0 Attachment
      > Not an XP answer, but one from my personal history: Everything I ever wrote
      > twice came out near perfect the second time. Rewriting is a serious luxury,
      > and can't be afforded all the time, but when it can it tends to produce high
      > quality code. If you can get the original authors to rewrite it from the
      > ground up, they have the concepts clear in their minds and they usually
      > stick them together in a much simpler way than they did the first time.


      Beware of "Second System Syndrome".

      In the rewrite, the programmer is tempted to do things
      the "right" way, add features, create extensibility, etc.
      It is reported that "second systems" often fail
      due to bloat.
    • Eric Hodges
      ... From: Andy Glew To: Sent: Monday, April 03, 2000 10:13 AM Subject: Re: [XP] Re: fix or rewrite? ...
      Message 2 of 20 , Apr 3, 2000
      • 0 Attachment
        ----- Original Message -----
        From: "Andy Glew" <glew@...>
        To: <extremeprogramming@egroups.com>
        Sent: Monday, April 03, 2000 10:13 AM
        Subject: Re: [XP] Re: fix or rewrite?


        > > Not an XP answer, but one from my personal history: Everything I ever
        wrote
        > > twice came out near perfect the second time. Rewriting is a serious
        luxury,
        > > and can't be afforded all the time, but when it can it tends to produce
        high
        > > quality code. If you can get the original authors to rewrite it from
        the
        > > ground up, they have the concepts clear in their minds and they usually
        > > stick them together in a much simpler way than they did the first time.
        >
        >
        > Beware of "Second System Syndrome".
        >
        > In the rewrite, the programmer is tempted to do things
        > the "right" way, add features, create extensibility, etc.
        > It is reported that "second systems" often fail
        > due to bloat.

        Hmmm. I've never seen this happen. Perhaps this is a benefit of laziness.
        I don't think adding features etc., is the "right" way. The second time I
        write something, it tends to be smaller and simpler.
      • Eric Hodges
        You have only yourself to blame if you let the customer know you are rewriting something. Of course they will ask for changes. They see it as an opportunity
        Message 3 of 20 , Apr 3, 2000
        • 0 Attachment
          You have only yourself to blame if you let the customer know you are
          rewriting something. Of course they will ask for changes. They see it as
          an opportunity to get what they want, and rightly so. The sorts of rewrites
          I've done aren't anyone's business but the coders.


          ----- Original Message -----
          From: "Urberg, John" <jurberg@...>
          To: <extremeprogramming@egroups.com>
          Sent: Monday, April 03, 2000 11:06 AM
          Subject: [XP] Re: fix or rewrite?


          > A worse problem than the programmer adding stuff is when the users find
          out
          > that you are rewriting the system and start inundating you with changes!
          >
          > > ----- Original Message -----
          > > From: "Andy Glew" <glew@...>
          > > To: <extremeprogramming@egroups.com>
          > > Sent: Monday, April 03, 2000 10:13 AM
          > > Subject: Re: [XP] Re: fix or rewrite?
          > >
          > >
          > > > > Not an XP answer, but one from my personal history: Everything I
          ever
          > > wrote
          > > > > twice came out near perfect the second time. Rewriting is a serious
          > > luxury,
          > > > > and can't be afforded all the time, but when it can it tends to
          > > produce
          > > high
          > > > > quality code. If you can get the original authors to rewrite it
          from
          > > the
          > > > > ground up, they have the concepts clear in their minds and they
          > > usually
          > > > > stick them together in a much simpler way than they did the first
          > > time.
          > >
          > >
          > > Beware of "Second System Syndrome".
          > >
          > > In the rewrite, the programmer is tempted to do things
          > > the "right" way, add features, create extensibility, etc.
          > > It is reported that "second systems" often fail
          > > due to bloat.
          > >
          >
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          extremeprogramming-unsubscribe@...
          >
          > Ad-free courtesy of objectmentor.com
          >
          >
        • Ron Jeffries
          ... It s a pretty famous syndrome. I ve fallen prey to it a few times myself. Ron Jeffries www.XProgramming.com
          Message 4 of 20 , Apr 3, 2000
          • 0 Attachment
            At 11:04 AM 4/3/2000 -0500, you wrote:
            > > In the rewrite, the programmer is tempted to do things
            > > the "right" way, add features, create extensibility, etc.
            > > It is reported that "second systems" often fail
            > > due to bloat.
            >
            >Hmmm. I've never seen this happen. Perhaps this is a benefit of laziness.
            >I don't think adding features etc., is the "right" way. The second time I
            >write something, it tends to be smaller and simpler.

            It's a pretty famous syndrome. I've fallen prey to it a few times myself.

            Ron Jeffries
            www.XProgramming.com
          • Ron Jeffries
            ... If the customer needs changes, they should get them, it seems to me. Isn t that kind of a basic XP principle? There must be something lurking here that I
            Message 5 of 20 , Apr 3, 2000
            • 0 Attachment
              At 11:28 AM 4/3/2000 -0500, you wrote:
              >You have only yourself to blame if you let the customer know you are
              >rewriting something. Of course they will ask for changes. They see it as
              >an opportunity to get what they want, and rightly so. The sorts of rewrites
              >I've done aren't anyone's business but the coders.

              If the customer needs changes, they should get them, it seems to me. Isn't
              that kind of a basic XP principle? There must be something lurking here
              that I don't understand ...

              Ron Jeffries
              www.XProgramming.com
            • Eric Hodges
              ... From: Ron Jeffries To: Sent: Monday, April 03, 2000 11:45 AM Subject: Re: [XP] Re: fix or rewrite?
              Message 6 of 20 , Apr 3, 2000
              • 0 Attachment
                ----- Original Message -----
                From: "Ron Jeffries" <ronjeffries@...>
                To: <extremeprogramming@egroups.com>
                Sent: Monday, April 03, 2000 11:45 AM
                Subject: Re: [XP] Re: fix or rewrite?


                > At 11:28 AM 4/3/2000 -0500, you wrote:
                > >You have only yourself to blame if you let the customer know you are
                > >rewriting something. Of course they will ask for changes. They see it
                as
                > >an opportunity to get what they want, and rightly so. The sorts of
                rewrites
                > >I've done aren't anyone's business but the coders.
                >
                > If the customer needs changes, they should get them, it seems to me. Isn't
                > that kind of a basic XP principle? There must be something lurking here
                > that I don't understand ...

                1. I'm not an XP user, just an interested observer.
                2. Customers should get the changes they want if and only if it makes good
                business sense. If they want something but aren't willing to pay for it,
                they shouldn't get it.
                3. There are times when an organization needs to serve itself before the
                customer. One example is rewriting a component. Sometimes this is none of
                the customer's business, and they don't need to be in the loop. As long as
                the rewrite doesn't harm the customer.
              • Ron Jeffries
                ... Who s paying? Ron Jeffries www.XProgramming.com
                Message 7 of 20 , Apr 3, 2000
                • 0 Attachment
                  At 12:47 PM 4/3/2000 -0500, you wrote:
                  >3. There are times when an organization needs to serve itself before the
                  >customer. One example is rewriting a component. Sometimes this is none of
                  >the customer's business, and they don't need to be in the loop. As long as
                  >the rewrite doesn't harm the customer.

                  Who's paying?

                  Ron Jeffries
                  www.XProgramming.com
                • Eric Hodges
                  ... From: Ron Jeffries To: Sent: Monday, April 03, 2000 1:31 PM Subject: Re: [XP] Re: fix or rewrite?
                  Message 8 of 20 , Apr 3, 2000
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Ron Jeffries" <ronjeffries@...>
                    To: <extremeprogramming@egroups.com>
                    Sent: Monday, April 03, 2000 1:31 PM
                    Subject: Re: [XP] Re: fix or rewrite?


                    > At 12:47 PM 4/3/2000 -0500, you wrote:
                    > >3. There are times when an organization needs to serve itself before the
                    > >customer. One example is rewriting a component. Sometimes this is none
                    of
                    > >the customer's business, and they don't need to be in the loop. As long
                    as
                    > >the rewrite doesn't harm the customer.
                    >
                    > Who's paying?

                    The customer. That's part of their job.

                    It doesn't do the customer any good in the long run if a company serves
                    their needs to the point that it goes bankrupt. That's why sometimes a
                    company has to take care of itself first. Just like a biological organism,
                    a certain amount of self interest is needed to survive.
                  • Ron Jeffries
                    ... I m sorry, but while I agree that the company shouldn t go bankrupt, I m not happy with the idea that you can long survive if not delivering business
                    Message 9 of 20 , Apr 3, 2000
                    • 0 Attachment
                      At 02:10 PM 4/3/2000 -0500, you wrote:
                      > > Who's paying?
                      >
                      >The customer. That's part of their job.
                      >
                      >It doesn't do the customer any good in the long run if a company serves
                      >their needs to the point that it goes bankrupt. That's why sometimes a
                      >company has to take care of itself first. Just like a biological organism,
                      >a certain amount of self interest is needed to survive.

                      I'm sorry, but while I agree that the company shouldn't go bankrupt, I'm
                      not happy with the idea that you can long survive if not delivering
                      business value. XP is about delivering business value all the time.

                      It's true that you can get buried. If you do, then the best thing may be to
                      start over ... but to start over by delivering new business value,
                      incrementally, all the time. Takes creativity, but I'd rather have to be
                      creative than explain why my coders weren't delivering value for any
                      extended period. That way lies big trouble. Been there, done that, got the
                      boot. ;->

                      R
                    • Kent Beck
                      The two risks are that you can t do today what you need to do today and you can t do tomorrow what you need to do tomorrow. If you have working code, you ve
                      Message 10 of 20 , Apr 3, 2000
                      • 0 Attachment
                        The two risks are that you can't do today what you need to do today and you
                        can't do tomorrow what you need to do tomorrow. If you have working code,
                        you've taken care of the former. Never lose that. Add tests and refactor
                        incrementally.

                        If you have crappy code that doesn't work, flush it. The bigger the pile,
                        the faster you should flush.

                        Kent
                      • Malte Kroeger
                        We have developed a product for about 7 years. It s been installed some hundred times and is currently delivering value for a 100 people company. The system
                        Message 11 of 20 , Apr 3, 2000
                        • 0 Attachment
                          We have developed a "product" for about 7 years.
                          It's been installed some hundred times and is currently delivering value
                          for a 100 people company. The system is C/C++. There was no refactoring,
                          no tests.

                          We have a very hard time delivering new functionality, because the system
                          is way too complicated. There seams to be no way to refactor your way out
                          of it. Rewrite is faster & easier.
                          We've already lost the pool position in the market, due to lack of new
                          functionality and missing robustness.

                          This is a situation when you have to do a rewrite behind the scenes, cause
                          there is no other way left.
                          And hope the company survives and can catch up afterwards when the new
                          lean and mean system is up and running.

                          Malte
                        • Eric Hodges
                          I think we may be talking about different kinds of customers. If I had developed a component for one particular user and no one else, then I can see your
                          Message 12 of 20 , Apr 3, 2000
                          • 0 Attachment
                            I think we may be talking about different kinds of customers. If I had
                            developed a component for one particular user and no one else, then I can
                            see your point. But if I've got components that are used by dozens or
                            hundeds or thousands of customers, and espeically if those components don't
                            have direct visibility to the customers, then it's my business how to manage
                            them.

                            I don't expect any of my current customers to embrace XP. They don't care
                            what process I use to develop the software, they just want to buy it. I
                            think this is another example of how generalizations are always false. :)
                            Usually.


                            ----- Original Message -----
                            From: "Tracie Karsjens" <tracie.karsjens@...>
                            To: <extremeprogramming@egroups.com>
                            Sent: Tuesday, April 04, 2000 2:22 AM
                            Subject: Re: [XP] Re: fix or rewrite?


                            > > > >3. There are times when an organization needs to serve itself before
                            > the
                            > > > >customer. One example is rewriting a component. Sometimes this is
                            > none of
                            > > > >the customer's business, and they don't need to be in the loop. As
                            > long as
                            > > > >the rewrite doesn't harm the customer.
                            > > >
                            > > > Who's paying?
                            > >
                            > > The customer. That's part of their job.
                            > >
                            > > It doesn't do the customer any good in the long run if a company serves
                            > > their needs to the point that it goes bankrupt. That's why sometimes a
                            > > company has to take care of itself first. Just like a biological
                            > organism,
                            > > a certain amount of self interest is needed to survive.
                            > >
                            >
                            > I'm with Ron on this. This is one of the hardest parts for me in terms of
                            > shifting my mindset to XP. For me to trust the customer and keep the
                            > customer in the loop and not do stuff "they don't need to know about" is
                            > tough. But how can we expect the customers to trust us to do what we are
                            > good at (program) if we don't trust them to do what they are good at (make
                            > business decisions)? The problem (and the challenge) is that rarely do
                            > programmers just program - of course we're involved with the business at
                            > some level.
                            >
                            > While I understand and fully identify with the sentiment of "It doesn't do
                            > the customer any good in the long run if a company serves their needs to
                            the
                            > point that it goes bankrupt," I wouldn't want a business person to say "We
                            > can't trust the programmers to XXX - after all it's not in their best
                            > interest if the project fails."
                            >
                            > That said, I see it that I have the responsibility to protect the customer
                            > from himself by telling him my concerns (communication) and listening to
                            his
                            > reasons (feedback). If he makes a decision I disagree with in spite of the
                            > conversation, I have to do my best in that situation and not do my thing
                            > anyway. (courage)
                            >
                            > Which leads me to my final conclusion that customers that only survive
                            > because of cowboy coders and by not knowing things, may not be the best
                            > candidates for XP - at least at first. Of course, the customer who
                            embraces
                            > XP, knows and approves of Continuous Refactoring, so in theory you would
                            > never need to scrap and rewrite a component.
                            >
                            >
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            extremeprogramming-unsubscribe@...
                            >
                            > Ad-free courtesy of objectmentor.com
                            >
                            >
                          • Ron Jeffries
                            ... Yes, you re right, we re talking about different situations. It is entirely appropriate for your company to make an internal investment decision to redo or
                            Message 13 of 20 , Apr 3, 2000
                            • 0 Attachment
                              At 04:11 PM 4/3/2000 -0500, you wrote:
                              >I think we may be talking about different kinds of customers. If I had
                              >developed a component for one particular user and no one else, then I can
                              >see your point. But if I've got components that are used by dozens or
                              >hundeds or thousands of customers, and espeically if those components don't
                              >have direct visibility to the customers, then it's my business how to manage
                              >them.

                              Yes, you're right, we're talking about different situations. It is entirely
                              appropriate for your company to make an internal investment decision to
                              redo or restructure some old technology. In that case, your marketing
                              department or your VP R&D is the customer in the XP sense.

                              At the same time, in JUST that situation, I've buried myself more than
                              once. I'd try to refactor my way out, as much as I hate that solution,
                              because I think it's safer. As Kent said above, if you have something that
                              works, it's generally best to hold on to it.

                              Regards

                              Ron Jeffries
                              www.XProgramming.com
                            • Eric Hodges
                              Now that I think about it, my experience with rewriting is mostly from my pre-refactoring (prefactoring?) days. I can t think of anything I ve had to rewrite
                              Message 14 of 20 , Apr 3, 2000
                              • 0 Attachment
                                Now that I think about it, my experience with rewriting is mostly from my
                                pre-refactoring (prefactoring?) days. I can't think of anything I've had to
                                rewrite since I started consciously refactoring my code. Perhaps merciless
                                refactoring removes the need for total rewrites.


                                ----- Original Message -----
                                From: "Ron Jeffries" <ronjeffries@...>
                                To: <extremeprogramming@egroups.com>
                                Sent: Monday, April 03, 2000 4:36 PM
                                Subject: Re: [XP] Re: fix or rewrite?


                                > At 04:11 PM 4/3/2000 -0500, you wrote:
                                > >I think we may be talking about different kinds of customers. If I had
                                > >developed a component for one particular user and no one else, then I can
                                > >see your point. But if I've got components that are used by dozens or
                                > >hundeds or thousands of customers, and espeically if those components
                                don't
                                > >have direct visibility to the customers, then it's my business how to
                                manage
                                > >them.
                                >
                                > Yes, you're right, we're talking about different situations. It is
                                entirely
                                > appropriate for your company to make an internal investment decision to
                                > redo or restructure some old technology. In that case, your marketing
                                > department or your VP R&D is the customer in the XP sense.
                                >
                                > At the same time, in JUST that situation, I've buried myself more than
                                > once. I'd try to refactor my way out, as much as I hate that solution,
                                > because I think it's safer. As Kent said above, if you have something that
                                > works, it's generally best to hold on to it.
                                >
                                > Regards
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                >
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to:
                                extremeprogramming-unsubscribe@...
                                >
                                > Ad-free courtesy of objectmentor.com
                                >
                                >
                              • Ron Jeffries
                                ... It s certainly supposed to ... Ron Jeffries www.XProgramming.com
                                Message 15 of 20 , Apr 3, 2000
                                • 0 Attachment
                                  At 05:29 PM 4/3/2000 -0500, you wrote:
                                  >Now that I think about it, my experience with rewriting is mostly from my
                                  >pre-refactoring (prefactoring?) days. I can't think of anything I've had to
                                  >rewrite since I started consciously refactoring my code. Perhaps merciless
                                  >refactoring removes the need for total rewrites.

                                  It's certainly supposed to ...

                                  Ron Jeffries
                                  www.XProgramming.com
                                • nick.thurn@db.com
                                  ... From: Andy Glew ... This is also my experience. Perhaps it proves the point of YouAintGonnaNeedIt. cheers Nick
                                  Message 16 of 20 , Apr 3, 2000
                                  • 0 Attachment
                                    ----- Original Message -----
                                    From: "Andy Glew" <glew@...>
                                    > >
                                    > > Beware of "Second System Syndrome".
                                    > >
                                    > > In the rewrite, the programmer is tempted to do things
                                    > > the "right" way, add features, create extensibility, etc.
                                    > > It is reported that "second systems" often fail
                                    > > due to bloat.

                                    > Hmmm. I've never seen this happen. Perhaps this is a benefit of laziness.
                                    > I don't think adding features etc., is the "right" way. The second time I
                                    > write something, it tends to be smaller and simpler.

                                    This is also my experience. Perhaps it proves the point
                                    of YouAintGonnaNeedIt.

                                    cheers
                                    Nick
                                  • nick.thurn@db.com
                                    ... This is a pretty clear question however the answer is a bit ambiguous. In a sane organisation the organisation is paying and oversees the direct customer.
                                    Message 17 of 20 , Apr 3, 2000
                                    • 0 Attachment
                                      Ron Jeffries wrote:
                                      > Someone wrote:
                                      > >3. There are times when an organization needs to serve itself before the
                                      > >customer. One example is rewriting a component. Sometimes this is none of
                                      > >the customer's business, and they don't need to be in the loop. As long as
                                      > >the rewrite doesn't harm the customer.
                                      >
                                      > Who's paying?

                                      This is a pretty clear question however the answer is a bit ambiguous.

                                      In a sane organisation the organisation is paying and oversees the direct
                                      customer. The question "should we do this at all?" has been asked and
                                      answered up front with a "yes". Oversight of the customer's use of funds
                                      occurs periodically and the original decision is revisited based on this
                                      information. In this case the customer is paying but there is an organisational
                                      escalation point/s (Steering Commitee) that may be sympathetic to the wider
                                      issue.

                                      In many organisations (particularly big ones) oversight of the
                                      customer may not occur on a per project level just an overall budget.
                                      The supplier of the budget may be ambiguous, chargeback's? global HO?
                                      local direct? regional HO? In this case the customer is pretty free to
                                      do what he/she likes with funds for or against the interests of the
                                      organisation. No escalation point really available but the organisation
                                      is still paying somewhere, somehow.

                                      cheers
                                      Nick
                                    Your message has been successfully submitted and would be delivered to recipients shortly.