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

Re: [XP] user story on prototyping

Expand Messages
  • David Carlton
    ... Well, okay. It is possible in some contexts to pin down a term to have a specific meaning. For example, I used to be a professional mathematician, and
    Message 1 of 66 , Sep 8, 2009
    • 0 Attachment
      On Tue, Sep 8, 2009 at 12:42 PM, davenicolette <dnicolet@...> wrote:

      > --- In extremeprogramming@yahoogroups.com, David Carlton <carlton@...>
      > wrote:
      > > On Tue, Sep 8, 2009 at 12:14 PM, davenicolette <dnicolet@...> wrote:
      >
      > > > So...does it enhance communication when words can have multiple
      > meanings?
      > > >
      > >
      > > Words do have multiple meanings,
      >
      > Yes.
      >
      > > it's not really a choice?
      >
      > Maybe.
      >

      Well, okay. It is possible in some contexts to pin down a term to have a
      specific meaning. For example, I used to be a professional mathematician,
      and mathematicians put in a lot of work making it clear exactly what certain
      words mean in certain contexts. So I know that, if I read the word "ring"
      in certain books, it means a specific sort of algebraic structure rather
      than, for example, the wedding band on my finger or the place where a boxing
      match happens.

      But turning general concepts into specific jargon is a _lot_ of work. Just
      getting trained to work with these specific definitions is a big investment,
      and these definitions have to be renewed periodically. For example, I'm
      fairly sure that even these days different math books use "ring" to mean
      slightly different concepts. (So a book might say early on something like
      "for the purpose of this book 'ring' means 'commutative ring'", trusting the
      latter term to be well-enough defined because of course the reader has read
      dozens of other books defining the latter.)

      This is one reason why we spend so much time on acceptance tests - that's
      one way of pinning down exactly what we mean by terms in one local context,
      of turning a vague concept understood differently by different people into a
      specific, narrow piece of jargon that we can all agree on. Or, to take a
      less formal approach, I can imagine having a shared glossary on a project -
      I've seen that work well in books that use terms in specific ways, possibly
      ways that they expect to be a surprise to a reader.

      I thought Michael Bolton's blog post on a checking/testing distinction was
      really interesting. So, now that I've seen that distinction, I wouldn't
      want to give it up. But I also wouldn't expect that, if I started using the
      word "testing" or "checking" in his sense that other people would have any
      clue what I was talking about, unless I took care to mark it as jargon and
      went out of my way to explain it. And I haven't made up my mind yet whether
      using the jargon testing/checking for that distinction is the best choice of
      words or not.

      --
      David Carlton
      carlton@...


      [Non-text portions of this message have been removed]
    • Keith Ray
      I ll repeat an old msg I wrote about Peopleware: I just checked: Peopleware says that programmers spend 50% of their time collaborating with one other
      Message 66 of 66 , Sep 29, 2009
      • 0 Attachment
        I'll repeat an old msg I wrote about Peopleware:

        I just checked: "Peopleware" says that programmers spend 50% of their
        time collaborating with one other person, and 20% of their time
        working with two or more other persons -- right there on page 62 of
        the second edition. That's 70% of the time collaborating with one or
        more people. Way before pair programming was formalized.

        30% of the time are people "noise sensitive" to quote the book.

        The authors (at that time) believed that the state of "flow" was a
        solitary one, and necessary for sustained thinking and programming.
        The book seems to equate non-solitary with "interruptions".

        Pair programming allows "shared flow". And, as eating in any busy
        restaurant will demonstrate - talking with one other person
        effectively enables you to filter out the speech of everyone else.

        However, to some extent, I think "flow" may be over-rated: in that
        state a solo programmer can generate reams of code without noticing
        duplication or other code smells / design flaws. TDD helps make it
        solo coding better by making you alternate between creating and
        critiquing - but having another perspective provided by a partner
        provide more effective critiques.


        On Tue, Sep 8, 2009 at 3:09 PM, Ricardo Mayerhofer
        <ricardo.ekm.listas@...> wrote:
        > I'd like to see your opinion about this. TDM writes in peopleware about
        > flow, a immersion time dedicated to the work itself. He also argues how
        > interruptions are bad to productivity and proposes teams to watch how
        > many hours they can work uniterrupted. So my question is: Do still think
        > this is a good advice? How this relates to pair programming? Is it
        > possible to be in flow when pair programming?
        > How about collaborative environment? Considering that in a collaborative
        > enviroment, many times you are interrupted to help people to accomplish
        > their work.
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to:   extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.comYahoo! Groups Links
        >
        >
        >
        >



        --
        C. Keith Ray, IXP Coach, Industrial Logic, Inc.
        http://industriallogic.com 866-540-8336 (toll free)
        Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
        http://agilesolutionspace.blogspot.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.