ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)

Mouse mouse at Rodents-Montreal.ORG
Fri May 27 10:29:10 CDT 2016


> I've worked under Agile and XP regimes and I hate both with a
> passion.  They were both a *huge* productivity drag (ever actually
> tried "pair programming"?)

Yes.  I've done agile and XP and even a little pair programming.

And...I agree and I disagree.

If you have a small project, something one person can do and you are
content with the result being in only one person's head, agile and XP
and the like are exactly what you say: a significant productivity lose.

But if you need the result to be in more than one person's head, or if
the project is such that one person can't handle it (too big, needs to
be done too fast, whatever), pair programming is - well, can be - a
substantial win overall.  It impairs _individual_ productivity for the
sake of _overall_ productivity.

Agile and XP are less about programming productivity in isolation and
more about customer interfacing - and therefore productivity in terms
of producing happy customers (where "customer" should be interpreted
liberally, not necessarily as "arm's-length entity that pays money").
If you're building something for yourself, if you're doing a
well-defined and highly predictable "here's the task, go away and come
back when it's done" job, they are of little to no use.  But if you're
building something where there's a nontrivial chance of the
requirements changing mid-job, and the coders and the consumer are
different, I find them to be of significant value - and that's a larger
fraction of the coding jobs than one might wish.

> It also seems to me that all the "greats" (incredible coders)

No, if you're idolzing lone-wolf coders producing one-person projects
on their own (or even very small teams, if they already know one
another well), agile will be somewhere between irrelevant and
obstructionist.

> and software projects or companies I loved or respected weren't
> "Agile".

Possibly.  I'd have to know which ones you have in mind to have any
chance of saying anything of value - and probably not even then, as
it's unlikely that whatever you have in mind is something I know
anything about the internals of.

I will hazard a guess that the projects/companies you're talking about
were not producing code for a customer, but were producing something
for themselves which, once produced, turned out to be appreciated.
(Perhaps they did so expecting that result, perhaps not - the critical
point is that there was no customer before/during coding.)  There, too,
because there is no customer during coding and thus no changing
requirements during coding, and no customer to be kept happy during
coding, agile and XP are irrelevant.  If that's the only kind of coding
you care about, or what to do, or whatever, yes, you should ignore
them.

A nontrivial fraction of the code I write falls into such categories.
But there is also a nontrivial fraction of the code I write that _does_
have a separate customer, with changing requirements.  While I don't
formally do agile, what I do do is in line with many of the principles
behind agile - things like "release early, release often", short
iterations, and constant customer involvement.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


More information about the cctalk mailing list