Why don't you go back to the days of DOS!! - Page 14


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 14 of 14 FirstFirst ... 4121314
Results 196 to 206 of 206

Thread: Why don't you go back to the days of DOS!!

  1. #196
    W.E. (Bill) Goodrich, PhD Guest

    Re: Why don't you go back to the days of DOS!!

    In article <3baf9bdf.4459429@news.devx.com>,
    kylix_is@hotmail.com (Mike Mitchell) writes:

    > On Sun, 23 Sep 2001 16:04:31 -0600, "W.E. (Bill) Goodrich, PhD"
    > <bgoodric@earthlink.net> wrote:


    > >Those (and the rest you mention) are management problems, not
    > >indications of the quality of their technology.


    > Ah, but the argument wasn't about the quality of their technology,


    Yes it was.

    > but about their technical superiority as a nation or political
    > organisation,


    Nope. Nor was it about the "technical superiority in marketing and
    management" of Sony (vs Phillips), or of any of the other pairings.
    It was about pure "quality of technology" vs results.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  2. #197
    Thomas Eyde Guest

    Re: Why don't you go back to the days of DOS!!

    Mike,

    This was a long tale. Does this reflectt actual experience or is it your gut
    feeling? I agree with you, a partner not contributing is a waste. This is
    not how pair programming is supposed to work. How confident are you that the
    non-contributing partner would contribute if he/she sat alone and no one to
    watch? A colleauge of mine told about a person it took months to reveal his
    true face: He was interested in money only, not to get the work done.

    I believe in pair programming, the short, few sessions I've joined so far
    gives me a good feeling. But I would hesitate to persue this further if you
    have actual experience advising against it.

    /Thomas



  3. #198
    Thomas Eyde Guest

    Re: Why don't you go back to the days of DOS!!

    How then can you have so strong opinion against pair-programming?
    /Thomas

    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3baf92dc.2152229@news.devx.com...
    > On Sat, 22 Sep 2001 21:58:32 +0200, "Thomas Eyde"
    > <thomas.eyde@online.no> wrote:
    >
    > >Does your experience prove pair programming to be ineffective?

    >
    > Never tried it, mate. Never had sex with a donkey either.
    >
    > MM




  4. #199
    Rob Teixeira Guest

    Re: Why don't you go back to the days of DOS!!


    "Thomas Eyde" <thomas.eyde@online.no> wrote:
    >Mike,
    >
    >This was a long tale. Does this reflectt actual experience or is it your

    gut
    >feeling? I agree with you, a partner not contributing is a waste. This is
    >not how pair programming is supposed to work. How confident are you that

    the
    >non-contributing partner would contribute if he/she sat alone and no one

    to
    >watch?


    A slacker will always find a way to be a slacker, in just about any situation.

    > A colleauge of mine told about a person it took months to reveal his
    >true face: He was interested in money only, not to get the work done.


    The value of good management is to
    1) not hire these types to begin with
    2) (because we know shifty people find a way to get hired anyway) to replace
    them with productive members as soon as possible, just like repairing any
    other part of a project that is taking a turn for the worst

    >I believe in pair programming, the short, few sessions I've joined so far
    >gives me a good feeling. But I would hesitate to persue this further if

    you
    >have actual experience advising against it.


    This underscores the argument about methodology in general. Every methodology's
    goal is to provide a clear, distinct, and predictable path to project success,
    while trying eliminating problems before they become problems. The trouble
    with most methodologies is that they make a vast number of assumptions. Therefore,
    the minute you're exact environment doesn't fit one of the assumptions, the
    methodology falls apart. In that respect, it's up to the manager, and the
    team in general (the team is the central most crucial part of a project),
    to find the methodology that fits their needs the best.
    If paired programming is working for your team, and results in gained productivity
    and high rates of project success, then you probably found what works for
    you. Over the years, you and your team will be able to further refine that
    methodolgy to bring more consistant and better results.

    -Rob

  5. #200
    Cali LaFollett Guest

    Re: Why don't you go back to the days of DOS!!

    Inline...

    > The value of good management is to
    > 1) not hire these types to begin with
    > 2) (because we know shifty people find a way to get hired anyway) to

    replace
    > them with productive members as soon as possible, just like repairing any
    > other part of a project that is taking a turn for the worst


    Agreed! Unfortunately step 2 is the norm and many managers, for some reason,
    find it hard to "fire" those types of individuals for fear of not being able
    to replace them or fear of having to "retrain" somebody else. These types of
    managers do not truly see the cost of keeping somebody that is detrimental.
    Dan Petit's "Real Visual Basic" book talks about this to some extent.

    > This underscores the argument about methodology in general. Every

    methodology's
    > goal is to provide a clear, distinct, and predictable path to project

    success,
    > while trying eliminating problems before they become problems. The trouble
    > with most methodologies is that they make a vast number of assumptions.

    Therefore,
    > the minute you're exact environment doesn't fit one of the assumptions,

    the
    > methodology falls apart. In that respect, it's up to the manager, and the
    > team in general (the team is the central most crucial part of a project),
    > to find the methodology that fits their needs the best.
    > If paired programming is working for your team, and results in gained

    productivity
    > and high rates of project success, then you probably found what works for
    > you. Over the years, you and your team will be able to further refine that
    > methodolgy to bring more consistant and better results.


    And this is the true point of all of this! I don't think one methodology
    will work for everyone. I think a development team should agree on the
    initial approach to how they want to accomplish their project and then be
    flexible enough to change when that approach starts to falter. In my former
    "paired programming" environment, it took a couple of month cycles until we
    had the kinks worked out. It was not a true form of XP but a mixture of
    traditional development and "paired programming". The best of both worlds so
    to speak.

    I agree with Mike in that the techniques that he describes works well for
    many companies or individual programming teams. I am currently back in that
    scenario of traditional development with my current company. I do miss the
    "paired programming" side of it that I left behind at my last company but
    that is not the current methodology in my current company and I have to be
    flexible enough to make it work.

    Irregardless which way the group chooses to go, the team in general must
    feel comfortable with it or, at some point, it will start to crumble.

    Each to his own. That is the part about programming that I like, there are
    so many ways to skin a cat and that most of the time, there is never one
    true correct answer. As long as it isn't truly detrimental to the project or
    the team, what works best for the team or individuals within the team is
    what should be used as the solution.

    Regards,
    Cal



  6. #201
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Why don't you go back to the days of DOS!!

    "Thomas Eyde" <thomas.eyde@online.no> wrote in message <news:3bb051c5$1@news.devx.com>...

    > This was a long tale. Does this reflectt actual experience or is it your gut
    > feeling? I agree with you, a partner not contributing is a waste. This is
    > not how pair programming is supposed to work. How confident are you that the
    > non-contributing partner would contribute if he/she sat alone and no one to
    > watch? A colleauge of mine told about a person it took months to reveal his
    > true face: He was interested in money only, not to get the work done.


    How are the tasks assigned to each person? Aim for tangible progress
    each and every workday.

    > I believe in pair programming, the short, few sessions I've joined so far
    > gives me a good feeling. But I would hesitate to persue this further if you
    > have actual experience advising against it.


    Some people are more easily distracted than others. This is by no means
    necessarily an indicator of low intelligence, however.

    --
    Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
    WARNING: I cannot be held responsible for the above They're coming to
    because my cats have apparently learned to type. take me away, ha ha!



  7. #202
    Tom Shelton Guest

    Re: Why don't you go back to the days of DOS!!

    The same reason he has such a strong opinion against VB.NET?

    Tom Shelton

    "Thomas Eyde" <thomas.eyde@online.no> wrote in message
    news:3bb05258@news.devx.com...
    > How then can you have so strong opinion against pair-programming?
    > /Thomas
    >
    > "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    > news:3baf92dc.2152229@news.devx.com...
    > > On Sat, 22 Sep 2001 21:58:32 +0200, "Thomas Eyde"
    > > <thomas.eyde@online.no> wrote:
    > >
    > > >Does your experience prove pair programming to be ineffective?

    > >
    > > Never tried it, mate. Never had sex with a donkey either.
    > >
    > > MM

    >
    >




  8. #203
    Mike Mitchell Guest

    Re: Why don't you go back to the days of DOS!!

    On Tue, 25 Sep 2001 11:48:03 +0200, "Thomas Eyde"
    <thomas.eyde@online.no> wrote:

    >I believe in pair programming, the short, few sessions I've joined so far
    >gives me a good feeling. But I would hesitate to persue this further if you
    >have actual experience advising against it.


    No, I have no eXPerience of it. Everyone I mentioned this too would
    find it totally alien to their way of working. Sure, if a research lab
    wants to pay me to act as a guinea pig or Versuchskaninchen, I'll try
    anything once!

    MM

  9. #204
    Mike Mitchell Guest

    Re: Why don't you go back to the days of DOS!!

    On Tue, 25 Sep 2001 11:50:28 +0200, "Thomas Eyde"
    <thomas.eyde@online.no> wrote:

    >How then can you have so strong opinion against pair-programming?


    Well, I can't imagine it being a lot of fun with that donkey...! Think
    about it!

    MM

  10. #205
    Mike Mitchell Guest

    Re: Why don't you go back to the days of DOS!!

    On Mon, 24 Sep 2001 22:20:41 -0600, "W.E. (Bill) Goodrich, PhD"
    <bgoodric@earthlink.net> wrote:

    >Yes it was.


    I think you should refer yourself to Mark Jerde's post which started
    this exchange of views. It's clear that he speaks of 'technical
    superiority'.

    MM

  11. #206
    Zane Thomas Guest

    Re: Why don't you go back to the days of DOS!!

    On Mon, 24 Sep 2001 15:33:28 -0600, "W.E. (Bill) Goodrich, PhD"
    <bgoodric@earthlink.net> wrote:

    >Now there you go again, Zane - a perfect example of the intellectual
    >dishonesty that Larry was talking about.


    Uh huh, you and Larry are no doubt impressing everyone with your profound
    insights and honesty.


    --
    The nice thing about standards is that
    there are so many of them to choose from.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center