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
