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

[Swift Griggs]

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