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

Re: [XP] Science vs. Engineering, UML and XP

Expand Messages
  • Kenneth Tyler
    ... Instead of by accident , think of it more like through interaction . You have a plan, you work, and in working you learn, you encounter difficulties,
    Message 1 of 4 , Mar 1, 2001
      >> 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".
      >>

      Instead of "by accident", think of it more like "through interaction". You
      have a plan, you work, and in
      working you learn, you encounter difficulties, which reveal how the
      situation has been changed, or ways that
      you did not consider things when you started, you change to take these
      things into account in a controlled way. This is the way a good cabinet
      maker builds a piece of furniture, or a painter paints a painting, a cook
      cooks a meal, or that people make love. It is typical of complex tasks.
      Complex tasks are complex not just because no one has taken the trouble to
      fully describe them, but because they change during the doing.

      Kenneth Tyler, Berkeley, CA
    • Ron Jeffries
      ... Very nicely put. Needs underlining. Consider it underlined. Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com
      Message 2 of 4 , Mar 1, 2001
        At 07:36 AM 3/1/2001 -0800, it seemed like Kenneth Tyler wrote:
        >Instead of "by accident", think of it more like "through interaction". You
        >have a plan, you work, and in
        >working you learn, you encounter difficulties, which reveal how the
        >situation has been changed, or ways that
        >you did not consider things when you started, you change to take these
        >things into account in a controlled way. This is the way a good cabinet
        >maker builds a piece of furniture, or a painter paints a painting, a cook
        >cooks a meal, or that people make love. It is typical of complex tasks.
        >Complex tasks are complex not just because no one has taken the trouble to
        >fully describe them, but because they change during the doing.

        Very nicely put. Needs underlining. Consider it underlined.

        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com
      • Glen B. Alleman
        See Rechtin (2001) for a similar discussion. I m putting up crown molding today at the condo, so I can tell you from experience that learning by doing is also
        Message 3 of 4 , Mar 1, 2001
          See Rechtin (2001) for a similar discussion.

          I'm putting up crown molding today at the condo, so I can tell you from
          experience that learning by doing is also based on tools (a fine Hitachi
          trim saw, a nail gun) and lots of practice, watching others do the job and
          some fundamental understanding of the strength of materials, having the
          farming plan (maintenance docs) so I know where to nail the back supports,
          and the patience to make careful measurements and cuts BEFORE bring out the
          nail gun. Spackle can fix lots of mistakes, but the builder always knows
          where the patches are.

          Glen Alleman

          > -----Original Message-----
          > From: Ron Jeffries [mailto:ronjeffries@...]
          > Sent: Thursday, March 01, 2001 9:55 AM
          > To: extremeprogramming@yahoogroups.com
          > Subject: Re: [XP] Science vs. Engineering, UML and XP
          >
          >
          > At 07:36 AM 3/1/2001 -0800, it seemed like Kenneth Tyler wrote:
          > >Instead of "by accident", think of it more like "through
          > interaction". You
          > >have a plan, you work, and in
          > >working you learn, you encounter difficulties, which reveal how the
          > >situation has been changed, or ways that
          > >you did not consider things when you started, you change to take these
          > >things into account in a controlled way. This is the way a good cabinet
          > >maker builds a piece of furniture, or a painter paints a painting, a cook
          > >cooks a meal, or that people make love. It is typical of complex tasks.
          > >Complex tasks are complex not just because no one has taken the
          > trouble to
          > >fully describe them, but because they change during the doing.
          >
          > Very nicely put. Needs underlining. Consider it underlined.
          >
          > Ronald E Jeffries
          > http://www.XProgramming.com
          > http://www.objectmentor.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/
          >
          >
        • JUDD John
          ... Thats true, but I suspect that most customers would have some concern over the process. After all I would like to think that, when I am driving through
          Message 4 of 4 , Mar 1, 2001
            > -----Original Message-----
            > From: Tim Burns [mailto:tburns@...]
            > Sent: Friday, 2 March 2001 0:39
            > To: extremeprogramming@yahoogroups.com
            > Subject: [XP] Science vs. Engineering, UML and XP
            >
            >
            > John Judd says:
            > > Message: 12
            > > Date: Thu, 1 Mar 2001 17:36:33 +1100 (EDT)
            > > From: JUDD John <john.judd@...>
            > > Subject: RE: RE: XP for Large Projects (Was Re: XP in telecom?)
            > >
            > >
            > >
            > > > -----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".
            > >
            >
            > Certainly the whole product would not be "development by accident".
            > There is a goal. The customer though, really should have no
            > concern with
            > the coding details of the product. They are only responsible for the
            > business requirements.
            >

            Thats true, but I suspect that most customers would have some concern over
            the process. After all I would like to think that, when I am driving through
            that tunnel with a billion tons of rock above me, the builders used the
            correct procedures, and built it strong.

            > The best analogy I can think of is that software development
            > is not like
            > building a building a bridge or a building, but more like
            > building a tunnel
            > through a mountain with a strange and convoluted geology of
            > impervious rocks
            > and bottomless pits. There is a way through the mountain,
            > and the customer
            > specifies points A to come in and points B to go out. Those are the
            > business requirements. The developers can use their
            > instruments to scan 10
            > feet or so in advance and can base their design accordingly,
            > so there is
            > always a continuous process of design. However, if they try
            > and design
            > everything up front, they will find themselves hemmed in by
            > rock or falling
            > into the abyss.
            >

            Most analogies fall down at some point. Certainly in such a plastic medium
            like software, the analogies about building and construction have tunnels in
            them that you could drive a road train through.

            Your tunnel analogy is good because it describes a process where not all the
            factors are known at the time of development. It has a problem in that the
            requirements are fixed, and will not change. Noone is going to say to the
            tunnel builder three-quarters of the way through that they want the exit at
            a different location, or that they want six lanes instead of four. At least
            they wont be able to do this without a substantial increase in cost.

            > The work the programmers do is the hardest work conceptually,
            > so again, the
            > analogy to the bridge or building is bad, because in that
            > case, its the
            > architects and planners doing the conceptual work and the
            > building is done
            > by laborers. In the case of the cave, both activities are
            > difficult, but by
            > far, the building is the most difficult part conceptually.

            I'm not sure about that. I don't find development to be that hard. I guess
            after twenty years of programming a lot of the essential skills are fairly
            well ingrained.

            I think that software development can be engineered. But its not the same
            engineering that is used for building a bridge, or tunnel, or new silicon
            chip, or genetic cure. We use different tools and practices. I think we need
            to stop looking at other engineering disciplines to guide us.

            > > 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
            > >
            > >
            >
            > This makes me think that, yes, but attacking BDUF, I am
            > attacking a lame
            > target. I suppose I described it as UML/RUP/CMM with the
            > thought in mind of
            > UML as a deliverable. I do find good uses for UML as a tool,
            > especially
            > when I need to code up a big, complicated chunk of
            > functionality and can't
            > keep it all in my head. Then I have UML on the whiteboard
            > next to my desk
            > and can keep referring to it, changing it, etc as I work through the
            > problem.
            >
            > XP probably hasn't been attacked yet, because its not being
            > done badly at
            > enough places. I have seen it though. I went out to do a
            > job and yes, we

            Actually XP has its fair share of enemies. The OTUG list has a few on it
            that dont like XP, and its my understanding that Slashdot has a lot of
            eXtreme Antagonists on it.

            > were in a bullpen doing pair programming (just two of us),
            > but the bullpen
            > was a conference room and we were just shoved in the corner
            > with crappy
            > chairs and systems admin were on the other side talking on
            > the phone and to
            > other people about completely unrelated stuff. It was
            > horrible. If that
            > was my only exposure to XP, then I would hate it for the rest
            > of my life.
            >

            It sounds like you were never given a real chance to get it going.

            regards

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