| David Lightstone 2006-07-12, 6:58 pm |
|
"CTips" <ctips@bestweb.net> wrote in message
news:12b9q6a4448fu78@corp.supernews.com...
> David Lightstone wrote:
>
> I think you've cottempletely misunderstood XP. It is *not* about making
> better programmers, or even applicable to good programmers. It is a good
> tool for getting the most work out of average programmers, rooted in a
> deep understanding of human nature.
I see you have decided to post the 10 rules of a XP process (well usually
Ron Jeffries posts the list). I'm sure Ron has a reference to a posting of
a previous incarnation of the list. Perhaps he will repose so that the
"official" presentation can ne used, rather than your interpretation.
I decline to comment on the list. Been there done that before. When I have
time I will see if I can locate one of my prior responses to the list. We
can see just how poorly I undestoud it 1 maybe 2 years ago.
>
> No overtime (aka 9-5)
> ---------------------
> To most programmers, its just a job. Don't confuse them with programmers
> who *want* to program, and will slowly go berserk if you don't let them.
> But, asks the experienced programmer, what about "flow"? What about
> working when you're most efficient? Well, most programmers don't
> experience "flow". Further, for most middleware applications, flow is not
> necessary.
>
> Now, if its just a job, you might as well let them do only 9-5. You're not
> going to get much more work out of them anyway. And it makes management
> look good.
>
> Choose a system metaphor
> ------------------------
> The average programmer is not going to be able to reason abstractly. A
> metaphor will help him visualize what needs to be done.
>
> If you can't find a good metaphor, you're probably tackling something that
> is beyond the ability of average programmers. Excellent canary.
>
> Code the unit tests first etc. (aka TDD)
> ----------------------------------------
> Its a great idea. If religiously followed, it will produce tests with
> branch-coverage of the code. Most programmers wouldn't produce any tests
> otherwise, so this is *way* better than the alternative.
>
> Now, the tests will not be minimal, nor will it have path-coverage, but so
> what? At least there are some tests. The applications they write are too
> small for there to be any reason to minimize the set of tests. The
> applications they write are too simple for there to be any reason to be
> overly concerned with path testing.
>
> Leave optimization till last
> ----------------------------
> Again, a great thing when dealing with average programmers. They are
> generally clue-less about how to optimize, so its better that they never
> do it. The applications they write don't have the kinds of performance
> requirements where you'd have to architect the solution differently. So,
> you might as well tell them to do it last, safe in the knowledge that
> there will never be time for them to screw around.
>
> Make frequent small releases
> ----------------------------
> People work better when faced with deadlines, so its better to make sure
> that they are always faced with a deadline. Its even better when the
> release is supposed to add business functionality - that way, everyone
> know the customer is waiting for it, so it had better get done by the
> dead-line.
>
> Pair programming
> ----------------
> Possibly the best idea to come out of extreme programming.
>
> Most programmers don't actually spend much of 9-5 programming. After
> accounting for time spent day-dreaming, web-surfing, reading e-mail, etc.,
> they might actually spend 10% of their time actually working. But with
> someone looking over their shoulders, they are forced to concentrate. They
> might actually program 25-30% of the time!!!
>
> Notice how this is so much better than installing a key-logger. Everyone
> is monitored at all times. Since the people doing the monitoring are
> familiar with what is being done, its more difficult to just do busy-work.
> Since they have a stake in the outcome of the project, they are motivated
> to actively monitor.
>
> And best of all, its in the name of programmer empowerment - hey, why
> complain about someone looking over your shoulder; we're not doing it to
> monitor you, its part of XP, and XP is all about the well-being of
> programmers.
>
> Truly a brilliant piece of social engineering.
>
> Move people around
> ------------------
> A necessary rule for pair programming to be effective. If the same 2
> people work together, they might get comfortable, and discover a shared
> interest in warcraft. Instead by shifting people around, you keep people
> on their toes - you never know who might be the stukach.
>
> Collective code ownership
> -------------------------
> Another piece of brilliant social engineering. The group is now
> collectively responsible for the success/failure of the project. The
> manager does not have distinguish between people who pulled their weight
> and those who slacked off. (In fact, given pair-programming and move
> people around, he probably can't). If the project fails, he can just say
> its a collective failure, so all of you get punished.
>
> This means that, as in any other collective, the good people are pressured
> by the team to work harder to make up for the not-so-good. It also gives
> people in the team incentive to identify to management underperformers
> early.
>
> And best of all for managers, they have complete deniability:
> "Sorry, Tom, your team members say you're not pulling your weight, so
> they've asked me to fire you"
>
> Customer is always available
> ----------------------------
> This has several great advantages.
>
> First, you have someone who is not part of the team, who is actively
> interested in monitoring whats going on. This puts more pressure on the
> team to deliver.
>
> Second, since the sucess/failure of the customer reps career gets tied to
> the project, you now have someone in your customers company who is going
> to do their best to get the results accepted, independent of quality.
>
> Finally, since the customer rep is supposed to have been monitoring the
> progress of the project all along, if the project slips, or is otherwise
> unsatisfactory, you can say "we did exactly what you asked for every
> iteration, you knew what was going on, so how come you're telling us now
> that you're not satisfied" (Make sure to put the adequate amount of
> indignation in that statement).
|