RE: Agile Development, Anyone?

Along the lines of two programmers, some decades ago there was the concept
of "chief programmer". In the concept s/he was responsible for the "hairy"
portions of the application. At my first employer we extended the concept
by bringing in the newer (more novice) programmers for a walk through of
those programs. We figured it didn't do the shop much good if they remained
novices, and the best way to learn was from the best. Several times the
C.P. learned from the novices by the questions they asked or comments they
made; I know because I was the C.P. there.

We went the other way, too, by having the novice walk through their code and
design with me and the lead programmer. We didn't do either one on every
single program because that would have been too time consuming, but the L.P.
and I would pick and choose which ones we thought were of "educational"
value. We liked to move programmers up; i.e., they could eventually take on
those "hairy" tasks.

Jerry C. Adams
IBM i Programmer/Analyst
Who ever says "Talk is cheap" hasn't spoken to a lawyer recently.
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, August 29, 2011 10:47 AM
To: Midrange Systems Technical Discussion
Subject: Re: Agile Development, Anyone?

On 8/29/2011 9:09 AM, David Gibbs wrote:

On 8/25/2011 11:57 AM, Buck wrote:

On 8/24/2011 5:46 PM, Sam_L wrote: I am a lifelong RPG programmer -
33 years and a bit - and I think that the agile philosophies have
much to offer me. My colleagues and management don't necessarily
share that view which constrains my ability to adapt particular
methodologies like pair programming. If I could though, I'd
definitely prefer a more agile group.

This is the biggest impediment to Agile / Scrum adoption ... it's a MAJOR

change. You have to change the way you THINK.

And some of it frankly makes me shudder. Pair programming in particular
is a concept that could be as damaging as it is helpful. Two people
doing one job? Just to break even you have to finish the job in half
the clock time with the same number of errors. Fewer errors is
certainly good, but enough to make up for an additional worker? I doubt
you get that sort of improvement for your best developers.

Personally, I think pair programming is probably much better for new
programmers than for experts. And I think other agile concepts are
probably the same: they make sense in some situations and not in others.

Joe