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

RE: [XP] RE: XP for Large Projects (Was Re: XP in telecom?)

Expand Messages
  • JUDD John
    ... Thats always a good thing. I ve been considering XP for a while now, and one day hope to be in a position to practice it. ... I dont know any customer who
    Message 1 of 3 , Feb 28, 2001
    • 0 Attachment
      > -----Original Message-----
      > From: Tim Burns [mailto:tburns@...]
      > Sent: Thursday, 1 March 2001 16:24
      > To: extremeprogramming@yahoogroups.com
      > Subject: [XP] RE: XP for Large Projects (Was Re: XP in telecom?)
      >
      >
      > I don't know if this is really on topic, but it got me
      > thinking about my
      > feelings on XP practices in general.
      >


      Thats always a good thing. I've been considering XP for a while now, and one
      day hope to be in a position to practice it.


      > In the debate between UML/RUP/CMM processes and lightweight software
      > processes like Extreme Programming and Crystal Clear, I firmly believe
      > lightweight processes are the best. I feel they are right
      > from a gut level,
      > because they approach software from a more scientific level than an
      > engineering level.
      > For example, science is exploratory. The most profound ideas
      > of science are
      > usually discovered by accident within the context of
      > pursueing a similiar
      > problem. Take the Kary Mullis' discovery of the Polymerase
      > Chain Reaction
      > for instance. PCR is a good example, because it is a process,
      > or even say a
      > program for copying DNA.
      >

      I dont know any customer who would be happy to have a developer say to them
      that they were approaching the solution to their problem with a "develop by
      accident approach".

      I look at XP, RUP, and any development methodology as engineering software.
      Sure, its possible that at some point in the process some discovery is
      needed, but the overall development of software should be an engineering
      approach.

      Please note that I am not equating engineering with BDUF, RUP, Agile, or any
      other method. Engineering (to me) is the application of knowledge to the
      solving of a problem, be it building a bridge or developing software.
      Research science is the application of techniques to discover knowledge. (A
      sweeping generalisation I know).


      > Certainly, no software process I have seen approaches PCR in
      > terms of its
      > impact on society, but I think the analogy is good. It wasn't
      > the case that
      > someone thought, "Hey, I want to replicate genes, I will
      > write up some UML
      > and have some design meetings and we will figure out how to
      > do it." No, it
      > was discovered as a by-product of simple, careful research in
      > genetics.

      Sure the discovery of how to replicate genes was made using careful
      research. However, the application of this newly discovered technology will
      require following the directions of the discovery. In other words it will
      require engineering.

      >
      > My best development work has always been a fortunate
      > by-product of lots of
      > unit testing and incremental development, always looking for the most
      > elegant solution. Sometimes in direct defiance of BDUF
      > managers that were
      > screaming at me to write pages and pages and pages UML and
      > design documents.
      > In the end, though, my code worked and the customer was
      > pleased, so I never
      > got fired, and eventually got my way. If I look back on
      > projects, there is
      > no way I could have known up front of the small object
      > patterns that fell
      > out and saved me a lot of time in the long run. In fact, I
      > think that design
      > up front can obscure quality development by locking you into
      > a framework
      > where the programmer can't or is discouraged from making
      > effective design
      > changes spontaneously.
      >

      Depends on the types of changes the programmer wants to make. YAGNI makes
      sense here.

      BDUF as in the non-iterative waterfall model is a bad thing IMHO. However,
      some 'lowercase' design is necessary. The developer does need a frame of
      reference, whether this is a use-case, user story, or some other way of
      describing a set of requirements doesnt matter.

      Software development also needs a plan. It cannot be approached
      accidentally. Science doesnt always know what it is looking for, ultimately
      engineering should.

      Incidentally, since design seems to be a dirty word in XP, perhaps we could
      use the word 'Plan' to describe how we go about developing software.


      > On the other hand, the more I learn about Extreme Programming
      > the more I
      > believe its subtle as hell. Many of the features are easy to
      > state, but I am
      > sure very easy to do badly. Pair programming for instance, it
      > seems pretty
      > trivial, two people sit down and code together. I think it
      > would be a gross
      > error though to say that doing that was doing "Extreme
      > Programming". In
      > fact, I doubt that pair programming on its own, and without
      > some mentorship
      > would not be that effective. It has to be the whole thing and
      > in the right
      > way. I wouldn't want to do Extreme Programming without a full on-board
      > support from everyone I worked with, and perhaps a boot camp with some
      > experts.
      >

      Agreed, buy-in is very important.

      regards

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