27 May
2016
27 May
'16
9:08 a.m.
On Fri, 27 May 2016, Mouse wrote:
Agile and XP are less about programming productivity
in isolation and
more about customer interfacing - and therefore productivity in terms of
producing happy customers
Well, as you suspected, I wasn't really thinking about that. That's the
convenience of not having to run a business, I suppose. However, I do see
your point. I feel sorry for the folks who have to live at the tip of the
customer spear, so to speak.
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.
You definitely have me nailed on this one, too. That's exactly who I'm
thinking of. I mentioned Carmak. He's sort of the poster child. No degree,
no management BS, and has actual successful releases and REAL code that
works extremely well and is very well written. However, yes, he's a wizard
in a cave (and nowadays seems more interested in rockets anyway).
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.
Yes, you are right. That's the kind of thing I'm thinking of, not customer
driven, customer facing type of projects. While I've been a part of those
types of efforts, I think for myself personally, it's definitely not the
right place for me. However, I certainly won't gainsay you on the benefits
of certain methods of interacting with them. It's just not something high
on my personal value-system.
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.
That's where I'm coming from, exactly. I know it's not the only
perspective, it's just mine.
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.
That's probably why you have a more nuanced and mature philosophy on such
things. Jobs I've had which were more "customer facing" generally didn't
last long. I have a truth and directness problem (read: lack of subtlety)
that doesn't usually endear me to those types of gigs. So, I mostly ignore
those types of "opportunities". Nonetheless, I'm probably poorer for it.
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.
I can appreciate some of the elements, also. It's just irritating when
they start turning it into meeting (oh wait... scrumm) hell and folks are
more focused on pushing the methodology than completing the project. That
and the forced social interaction are negatives for me, personally.
However, I might be describing my own "issues" here more than any formal
argument or philosophy.
-Swift