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

Re: XP Crash and Burn (Re: [XP] Poll results forextremeprogramming)

Expand Messages
  • Niclas Olofsson
    These are pretty lenghty mails, but I sincerely hope that someone out there feel that they might learn something from our stupid misstakes. ... Pretty much so
    Message 1 of 9 , Sep 30, 2001
    • 0 Attachment
      These are pretty lenghty mails, but I sincerely hope that someone out
      there feel that they might learn something from our stupid misstakes.

      "C. Keith Ray" wrote:
      > So... the original XP project was 8 developers for 4 months, replaced (4
      > months after initiation?) by a non-XP project of 3 developers for 2 months.

      Pretty much so with the exception of 3 developers on 2 months. For the
      first release we where 2 1/2 developer. I did the serverside and another
      did client side. Another (the 1/2 guy) got permission to work on 1
      class, a servlet, as good as he could. The whole project sort of turned
      "Closed Source". Myself I worked 29 days straight, no less than 14 hours
      and no more than 36, so 2 month is not correct when it comes to the
      amount of effort that was put in. On the client-side the pace where
      somewhat slower, and after the first release most of the serverside was
      done while the second release was mostly clientside.

      > Do you think things would have been better if the original XP project had
      > been 4 people instead of 8?

      Yes I do. You mention learning organisations. I agree 100 on that. I
      would have said something about lack of personal initiative but you put
      it so much better. If I ever get the chance to try again (or redo this
      one) I'd use (or at least start with) the interested parties. But on the
      other hand, the client side guy, I think he likes XP now, he didn't
      earlier :-)

      But, the project acctually started with fewer than 8. People went away
      on summer vacations one month into the project, and not all at the same
      time. This was something that was taken into calculations even though
      not controlled in anyway. Looking back, this should have been handled a
      lot better, even though it would have been hard due to the companys
      liberal view on staff management.

      > Do you think things would have been better if the original XP project had
      > two-week iterations?

      Not sure if that would have made any difference. Our user stories where
      choosen to be _very_ simple and short in duration because we wanted to
      be able to keep track on the project to be able to learn on the way. We
      usually have weekly "jourfixes" (30min-1h) where we discuss ongoing
      projects and people get the chance to request help and inform others of
      their projects. Thus, we figured that we would just jourfix to discuss
      team stuff (since everybody where supposed to work on the same project
      for once).

      > Do you think things would have been better if the original XP project had
      > used "Process Reviews" for an hour each iteration?

      Jourfix...

      > does this mean that the less-experienced ended up resenting the
      > more-experienced?

      Hmm .. Not always. One of the guys (less-experienced) told me one day
      that he wanted me to go over his code over the evening and refactor
      whatever I found. He told me that the last time that happend he had
      learned so much from it so he wanted to go through it again. But at that
      time, this wasn't an XP project anymore (just very agile) so I don't
      think that is really representative. But I think he differs from some of
      the others in the way that he has, on several occations, expressed that
      he loves working with the rest of us because he get to learn so much
      from us.

      > I know that refactoring code "behind someone's back" can lead to
      > resentment... did your team pair-program with the original coder when
      > refactoring their code?

      Not always.

      > Refactoring code "in front of someone's back" can also lead to resentment,
      > if you not very diplomatic about it.

      We took our share of that too, yes.

      > However, if the code was written by a pair rather than a solo, there is
      > usually less personal feelings about the code. Was all code produced by
      > pairs?

      In the end, I guess very little.

      In another mail Ron wrote:
      > Finally, here are the XP practices. Please rate your project on
      > whether, and how well, they were done. A score and a comment will be
      > interesting.

      I'll do my best.

      "C. Keith Ray" wrote:
      > * Release and Iteration Planning
      > * Programmers sign up for tasks

      I rate that the plan for this was good. We had an old product to point
      at and a lot of experience in the domain. Also the plan was far more
      extensive than the team got to know, I figure simply because we didn't
      want to scare them. It's a product, thus this project doesn't really
      have an end :-) I made a very schetchy powerpoint presentation with
      basically 3 questions.

      - Are we building the right system?
      - Are we building it right?
      - Are we building it the right way?

      Then we left for a trip to Norway to discuss this with the whole team
      (including our "customer", the boss). This was acctually the time where
      the decision to use XP was taken. When we came back we sat down with our
      customer and tossed around some stories to start with. They where simple
      and choosen so that after a week we would get a good flat-line (smoke
      without fire) and our infrastructure at place. At this point people did
      sign up for stuff and pairs where formed. This was also the first time
      someone started asking for the project manager.

      > * Pair programming

      We did this good and bad (I still feel like it never really got started
      so please excuse the lack of info on this). We didn't install separate
      workstations for pair-programming which is something I regret today. We
      discussed it, but in the end it wasn't practically possible without
      heavy re-arrangement of the complete office. I noticed on several
      occations that a lot of the workstation-owners checked mail and browsed
      the web while their partner where observing very un-interested behind
      them. I didn't say anything about it because we had discussed it (and
      agreed), and I wanted to give the partner a chance to confront it
      themselves. Never happend and none complained, and it never happend to
      me.

      > * On-site customer

      Very good. This is something that we have kept, but also something that
      we have always practiced somehow. We are a product development company
      so this is pretty much the way it works. Our boss has a background as a
      master coder mixed with a strong sense for business and domain
      knowledge. We also have had pilots on our old system with close
      collaboration with real customers.

      > * Small releases

      Hmm ... we never got a release out of the XP project really.

      > * Metaphor

      We had an old system running to point at. We use metaphor constantly for
      smaller stuff (the ones that are to advanced to be talking about in
      techy terms even among the developers), but we have always done that.
      But our system is very close to reality and the reality we have is IMHO
      the best metaphor we can find. Everybody understands it.

      > * Unit Tests (test-first)

      Myself I started practise this almost a year ago now. This was because I
      was interested and later found it superior to what I had been doing up
      till then. Today I don't write a single line of code without test and
      doing it test-first. Some of the other developers we have adopted this
      too when they saw the benefits of it, but not all have. This seem to be
      hardest to get the less-experienced to grasp and to adopt. But it was
      agreed on that we would practice it and we had several occations where
      we first did it the old way, scratch the code and did it test-first with
      unit-tests, just to learn the difference.

      > * Acceptance Tests

      Hard to do when you haven't had anything up and running... but this was
      covered and we know how to do it.

      > * Merciless Refactoring

      We did this as soon as we could. A lot of the refactoring where done to
      scale down the implementation, strip out unnecessary stuff (hooks in the
      code, so to speak). I have the feeling that many times we did
      refactoring because of two things; 1) test-first wasn't practiced and
      thus the code was bloated, 2) Bad judgment-calls from the programmers or
      simply bad design. Sometimes it was a regular cleanup, and sometimes it
      was to same some code (reuse) before a complete rewrite (to further
      improve design).

      > * Simple design

      Very simple. We have a quite complex production environment (it is
      supposed to run by an ASP). I did the original architecture which was
      kept at a minimum. Our complete business object model captures all of it
      with 3 objects and two set of services, and they are very simplistic.
      Instead we use XML technology to provide extensibility. Our target is
      60.000 users where up to 15% is concurrent, thus quality and effeciency
      of the code is vital. If you have these requirements, you always stick
      to simple design :-\
      A lot of the stuff was left oút of the original paperwork because of
      YAGNI. This is something we had a small problem with because YAGNI isn't
      always that fun. A programmer that can't put all the magic hooks and
      fancy ideas into the code just because it isn't going to be needed,
      isn't always a happy programmer. It's hard to show-off when you are only
      supposed to do what is needed. Myself and some others have on the other
      hand discovered that YAGNI often provokes you to write better, more
      solid code and get our satisfaction from the increased quality instead.

      > * Collective code ownership
      > * Continuous integration
      > * Coding Standard

      6 months prior to this project I discovered that I had a deep interest
      in source code management (didn't even know it myself). So I spent a
      couple of weeks reading up on it and learned everything I could about
      it. We also have another developer (a real guru) that knows SCM. We had
      a small problem with the rest to get them to understand how to use P4
      (Perfoce) so we have put a lot of attention to this. I also figured that
      collective code ownership demands quite much from both the SCM system
      and it's users, thus we put even more effort into it. In the end I would
      say that we where (and still are) very prepared for this when it comes
      down to tools. HOWEVER, collective ownership is a lot about respect,
      isn't it. It require that you follow guidelines and don't develop it
      into some form of anarchy. To some extend I think this happend to us.
      I had prepared myself for XP failure detection by studying among other
      things, branch patters/behaviors. I knew that the day that I would find
      one or more runaway branches in the tree, we where having problems. This
      was finaly how I sort of "faced the problem" since it was exactly what
      happend.
      The good thing about this is however that it is The Thing (with a big T)
      that people do learn by misstake. Do a misstake on this end and I
      promise that you'll never do it again (unless you are really stupid).

      > * Open workspace

      We have 3 rooms. One with 3 guys, one with 4 and one with our guru :-)

      I think this is important and next time around I would change it (the
      managment would simply have to move).

      > * Sustainable Pace aka 40-hour week

      Half of the guys commute 2h every day. They go 40h by the second. Me and
      a couple of others do more (60-70) but we do a lot of "interesting"
      stuff that we never get the time to do otherwise. None of us have much
      of a life either :-)
      When the project crashed it went up to something like 100-130h/week.

      > (I notice that <http://www.extremeprogramming.org/rules.html> says "Fix XP
      > when it breaks".)

      "All of your developers must know exactly what to expect from each
      other, having a set of rules is the only way to set these expectations."

      I agree, but feel that we failed on that too.

      Cheers,
      /Niclas
    • Niclas Olofsson
      ... Well, if you ever hear about one taking place in sweden, or anyone in sweden you know of that should hold one, let me know. I must be honest, I haven t
      Message 2 of 9 , Sep 30, 2001
      • 0 Attachment
        "C. Keith Ray" wrote:
        > I think a week's training and a Coach are two key factors for success with
        > XP.

        Well, if you ever hear about one taking place in sweden, or anyone in
        sweden you know of that should hold one, let me know. I must be honest,
        I haven't heard of too many swedish companies that even had a look at XP
        yet (but I do know some).

        Don't know, but I get the feeling that we are too stiff to embrace XP
        fully. Why do you think we are so much into standards (especially ISO)?
        Of course it's because they change so seldom. <G> We hardly understand
        that fact that we aren't vikings and rulers of the north anymore, and
        now you ask us to embrace change?!

        :-)

        But seriously, I'd be happy to arrange something in Sweden (or northern
        Europe) if someone volunteer to be keynote speaker and hold some
        seminaries. How about Q1-2002? Anyone avalible?

        Cheers,
        /Niclas
      • Mike Clark
        ... This is a very honest and important observation of YAGNI. How better off might we be as an industry if being a show-off meant you had delivered releases
        Message 3 of 9 , Oct 1, 2001
        • 0 Attachment
          Niclas Olofsson wrote:

          >
          > > * Small releases
          >
          > Hmm ... we never got a release out of the XP project really.
          >
          >
          > > * Simple design
          > <snip>
          > A lot of the stuff was left oút of the original paperwork because of
          > YAGNI. This is something we had a small problem with because YAGNI isn't
          > always that fun. A programmer that can't put all the magic hooks and
          > fancy ideas into the code just because it isn't going to be needed,
          > isn't always a happy programmer. It's hard to show-off when you are only
          > supposed to do what is needed. Myself and some others have on the other
          > hand discovered that YAGNI often provokes you to write better, more
          > solid code and get our satisfaction from the increased quality instead.

          This is a very honest and important observation of YAGNI. How better off might we be
          as an industry if being a show-off meant you had delivered releases rather than added
          fancy ideas? Somehow it seems we put a lot more value on the latter.

          Mike
        • Brian C. Robinson
          ... I am certainly following the thread with interest. And this is a discussion group, made for discussing.
          Message 4 of 9 , Oct 1, 2001
          • 0 Attachment
            At 10:24 PM 9/30/01, you wrote:
            >These are pretty lenghty mails, but I sincerely hope that someone out
            >there feel that they might learn something from our stupid misstakes.

            I am certainly following the thread with interest. And this is a
            discussion group, made for discussing.
          • Urs Keller
            ... I would have suspected that the experienced programmers react more strongly to criticism than the less experienced ones. ... XP changed the rules of the
            Message 5 of 9 , Oct 1, 2001
            • 0 Attachment
              "Niclas Olofsson" wrote:
              > We do communicate a lot with each other (always has been
              > that way) but the one noticeable difference now from before is the lack
              > of respect that somehow developed during this period. I think that was
              > what in the end made it fail (*).

              "Niclas Olofsson" wrote:
              > (*) I should perhaps add that I think merciless refactory was what
              > started that trend (at least that's what I'm told). People say that
              > there is a factor 100 on experienced programmers, and this tend to show
              > during refactory. Less good programmers sometimes (if not always) have a
              > hard time not taking it personally.

              "Niclas Olofsson" wrote:
              > Not always. One of the guys (less-experienced) told me one day
              > that he wanted me to go over his code over the evening and refactor
              > whatever I found.

              I would have suspected that the experienced programmers react more
              strongly to criticism than the less experienced ones.

              "Niclas Olofsson" wrote:
              > A lot of the refactoring where done to scale down the implementation,
              > strip out unnecessary stuff (hooks in the code, so to speak). I have
              > the feeling that many times we did refactoring because of two things;
              > 1) test-first wasn't practiced and thus the code was bloated, 2) Bad
              > judgment-calls from the programmers or simply bad design. Sometimes
              > it was a regular cleanup, and sometimes it was to same some code
              > (reuse) before a complete rewrite (to further improve design).

              XP changed the rules of the game and probably the experienced
              programmers were not so experienced anymore. For example: YAGNI (You
              aren't gonna need it) outdid programming for the future with hooks
              and stuff.

              XP accelerates learning through visibility and concrete feedback. In
              other words conflicts come to the open quickly, faster than with other
              methodologies.

              > Some of the other developers we have adopted test-first programming
              > too when they saw the benefits of it, but not all have. This seem to be
              > hardest to get the less-experienced to grasp and to adopt. But it was
              > agreed on that we would practice it and we had several occations where
              > we first did it the old way, scratch the code and did it test-first
              > with
              > unit-tests, just to learn the difference.

              Pair programming does a great job at educating team members on test
              first programming, merciless refactoring, YAGNI. These practices are
              hard to grasp if you haven't seen them in practice.

              Urs
            • Bill Wake
              ... Niclas - I hope you ll keep the mail coming as long as you have patience to answer questions. (You ve been a great sport so far!) This is great stuff -
              Message 6 of 9 , Oct 1, 2001
              • 0 Attachment
                --- In extremeprogramming@y..., Niclas Olofsson <gurun@a...> wrote:
                >
                > These are pretty lenghty mails, but I sincerely hope that
                > someone out there feel that they might learn something from
                > our stupid misstakes.

                Niclas - I hope you'll keep the mail coming as long as you have
                patience to answer questions. (You've been a great sport so far!)
                This is great stuff - definitely going into my "keeper" file.

                --
                Bill Wake William.Wake@... www.xp123.com
              • Niclas Olofsson
                cannibals!! ;-) Yes, I ll keep answering as long as there are questions. Not all have been said and some of it is going through private review right now (if
                Message 7 of 9 , Oct 1, 2001
                • 0 Attachment
                  cannibals!!

                  ;-)

                  Yes, I'll keep answering as long as there are questions. Not all have
                  been said and some of it is going through private review right now (if
                  you ask the wrong question you get another essay). I'm completely
                  lacking prestige so I belive I can take it, whatever it would be. Just
                  have to think about my fellow komprades integrity since they didn't
                  exactly ask for a public review.

                  Cheers,
                  /Niclas

                  Bill Wake wrote:
                  >
                  > --- In extremeprogramming@y..., Niclas Olofsson <gurun@a...> wrote:
                  > >
                  > > These are pretty lenghty mails, but I sincerely hope that
                  > > someone out there feel that they might learn something from
                  > > our stupid misstakes.
                  >
                  > Niclas - I hope you'll keep the mail coming as long as you have
                  > patience to answer questions. (You've been a great sport so far!)
                  > This is great stuff - definitely going into my "keeper" file.
                  >
                  > --
                  > Bill Wake William.Wake@... www.xp123.com
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  >
                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

                  --
                  Niclas Olofsson - http://www.ismobile.com
                  Product Development, isMobile, Aurorum 2, S-977 75 Luleå, Sweden
                  Phone: +46(0)920-75550
                  Mobile: +46(0)70-3726404
                • Mike Clark
                  ... isn t ... only ... other ... instead. This is a very honest and important observation of YAGNI. How better off might we be as an industry if being a
                  Message 8 of 9 , Oct 2, 2001
                  • 0 Attachment
                    Niclas Olofsson wrote:

                    >
                    > > * Small releases
                    >
                    > Hmm ... we never got a release out of the XP project really.
                    >
                    >
                    > > * Simple design
                    > <snip>
                    > A lot of the stuff was left oút of the original paperwork because of
                    > YAGNI. This is something we had a small problem with because YAGNI
                    isn't
                    > always that fun. A programmer that can't put all the magic hooks and
                    > fancy ideas into the code just because it isn't going to be needed,
                    > isn't always a happy programmer. It's hard to show-off when you are
                    only
                    > supposed to do what is needed. Myself and some others have on the
                    other
                    > hand discovered that YAGNI often provokes you to write better, more
                    > solid code and get our satisfaction from the increased quality
                    instead.

                    This is a very honest and important observation of YAGNI. How better
                    off might we be
                    as an industry if being a show-off meant one had come through on
                    delivery rather than added
                    cool ideas? Somehow it seems we put a lot more value on the latter.

                    Mike
                  • C. Keith Ray
                    ... Can you tell us more about this? At the end of the first week/iteration, you should have had something to show the Customer, something that QA could test
                    Message 9 of 9 , Oct 2, 2001
                    • 0 Attachment
                      on 10/2/01 6:42 AM, Mike Clark at mike@... wrote:

                      > Niclas Olofsson wrote:
                      >
                      >>
                      >>> * Small releases
                      >>
                      >> Hmm ... we never got a release out of the XP project really.

                      Can you tell us more about this? At the end of the first week/iteration,
                      you should have had something to show the Customer, something that QA could
                      test (do you have QA people?)
                    Your message has been successfully submitted and would be delivered to recipients shortly.