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

Re: [XP] Blog Entry - Call it what it is!

Expand Messages
  • Michael Dubakov
    Well, this is in people nature. They often blame something not even seen that. Many people don t get what agile development is. They try it, fail a project and
    Message 1 of 39 , Sep 26 10:46 AM
    • 0 Attachment
      Well, this is in people nature. They often blame something not even
      seen that. Many people don't get what agile development is. They try
      it, fail a project and blame it. It happens and it will happen again.

      What we can do? Explain, train, communicate, etc.
      Maybe we as a community may have popular social web-site with
      extensive clarifications and answers to all common questions (like
      stackoverflow.com). Not sure whether it will be very helpful though...

      Michael Dubakov
      http://www.targetprocess.com/blog


      > What bothers me is that I've seen people "blame" a process when they
      > didn't really use it. Why, then, is it OK to laud a process when in
      > fact the people did much more?
      >
      > It's an interesting dichotomy to me, but evidently is isn't all that
      > interesting to anyone else. I'll shut up now.
      >
      > Dave Rooney
    • kentb
      Chris, Your summaries of my statements seems accurate, so as far as I can tell you are only wrong in thinking you are wrong :-) I was responding to a statement
      Message 39 of 39 , Sep 29 8:27 AM
      • 0 Attachment
        Chris,

        Your summaries of my statements seems accurate, so as far as I can tell you
        are only wrong in thinking you are wrong :-)

        I was responding to a statement something like, "Not using TDD is risky
        behavior." My (summarized) response was, "But many companies don't want what
        TDD can deliver and don't have experience with it, so from their perspective
        adopting TDD is the risky behavior."

        I try to be careful about dogmatic statements, having peddled so many of
        them in the past. That's what I was really responding to. There is a context
        in which adopting TDD is risky. There is another context in which not
        adopting TDD is risky. There is a huge, interesting middle ground where it
        could break either way. Oh, and time can change the contexts one to the
        other.

        Does this clarify the conversation for you?

        Regards,

        Kent Beck
        Three Rivers Institute

        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Chris Wheeler
        Sent: Saturday, September 27, 2008 12:26 PM
        To: extremeprogramming@yahoogroups.com
        Subject: Re: [XP] Blog Entry - Call it what it is!



        On Fri, Sep 26, 2008 at 9:00 PM, kentb <kentb@earthlink.
        <mailto:kentb%40earthlink.net> net> wrote:

        > The thing I see is that many organizations don't see the need for the kind
        > of confidence that TDD can produce. They spend less developer time on
        > quality but still get satisfactory results. For such an organization,
        > adopting TDD would be risky--they would be investing without the
        > expectation
        > of return.
        >

        I'm having trouble getting the meaning of this statement. First, if an
        organization doesn't see the need for the kind of confidence TDD can
        produce, does that mean that the organization can't see the need because
        they don't have that need, or does it mean that they are blind to the fact
        that they need it?

        Also, spending less developer and getting satisfactory results sounds pretty
        good to me. So, I'm really perplexed: if there is no necessary or
        demonstrable gain, why would we expect an investment in something that has
        no expectation of return?

        > I believe that better overall throughput is possible by shifting
        investment
        > in quality to the developers, but again, many organizations don't see the
        > need for better overall throughput. Again, for such an organization,
        > adopting TDD is the risky position.

        Once again, same question - if an organization doesn't see the need for
        better throughput, then why would it try to increase throughput? Also, is
        better throughput always necessary? What if my throughput already satisfies
        customers, and increasing throughput would not increase sales? In this
        light, investing in something with no demonstrable gain makes no sense.

        > I wish that software development and software developers had higher
        > aspirations, but I can't force that to happen, only hold them myself and
        > try
        > to support others who do as well.
        >

        Now this is an interesting statement, something that I've thought about
        recently. My wife is taking a course about the history and purposes of adult
        education. Something that she has been reading and writing about is the
        shift in motivation to educate oneself. In the past century, education has
        shifted from something that one does to better oneself and one's social
        circle to something one does to make oneself more useful to an economic end.

        Nowadays, companies have influence on what a person learns, but rarely can a
        company control someone's aspirations. Thus, it makes sense to me that there
        are lot of programmers out there who are not only in the business because it
        made economic sense, but are also actively pursuing ongoing education to
        satisfy the demands of their employers so that they can pursue higher
        rewards. But, they may aspire to things that are altogether different than
        building high quality software because, to an extent, their hearts aren't in
        it.

        I, for instance, like programming, and will fiddle in just about any
        language. But I am interested in XP and agile because my company got
        interested in it. I have no aspiration to build really great software: I do
        that mainly because my employer needs to sell good software and I need to
        build it for them and I'm decent at it. Rather, I aspire to study philosophy
        and literature and write something of substance one day. I also aspire to
        artistic expression and am trying to explore the things that will let me do
        that.

        So, I'm not so surprised that great software is the aspiration of most
        software developers.

        Chris.

        [Non-text portions of this message have been removed]






        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.