ASM, Clancy & Harvey, and Agile (Re: vintage computers in active use)
swiftgriggs at gmail.com
Fri May 27 11:08:45 CDT 2016
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.
More information about the cctalk