[mcguire]

One of the most entertaining conferences I ever attended was Usenix, several years ago. The paper sessions typically went like this: a grad student would stand up and present his and his advisor's research. In the sbsequent question-and-answer period, one of a small number of grey-beards (you'd recognize their names, but I can't remember who exactly it was; I'm old, too) would come to the mic and ask some variant of, "when we tried that back in the '80s, it didn't work because of.... How are you dealing with the problems?" There was never any real answer. (To be truthful, there were also a number of responses along the lines of "Why didn't you cite our earlier work?" which were more annoying since the typical true answer would have been "Because you only published it in a single post in rec.arts.no-one-reads-this." Bah.)

Since then, I've learned one thing: experience in this field doesn't give you any advantage. Or, more precisely, Cassandra, it doesn't give you any advantage that anyone will pay attention to.

I've had many similar conversations since that conference, usually along the lines of:

Them: "We should do X."

We: "That didn't work the last time; A, B, and C happen and only super-genius levels of D will get you out of the mess, which we don't have."

Them: "But X is the hot newness and everything's different this time, anyway."

Or sometimes:

We: "We're doing Y."

Them: "That's stupid, everyone is doing Z now." (Them almost never has more than 2-3 years of experience, by the way.)

We: "No one we've hired in the last ten years knows how to do Z, Z offers no actual advantage over Y, and I'd personally prefer not to have to deal with 27 different ways of doing the same thing."

Them: "I'm doing Z."

We: "Great. You'll be solely responsible for that project until you quit, then we'll throw it away and rewrite it. Just like last time."

Sure, you can keep up with the technology fashion; that's fairly easy. But it's a bit dispiriting to see the same problems in the new tech from the last time the dharma wheel rolled around. And to be unable to convince the new kids not to try to cross the railroad bridge because the 12:15 really does have a good on-time record. The entertainment value of watching projects hit the same shoals eventually loses its charm.

[hga]

Indeed. I've worked for more than one company that died because it didn't listen when I said, e.g., this won't work because math. In that case, simple multiplication and comparing the result to currently available IOPS.

A lot of people just don't care until they actually crash into the brick wall, but in a start up that's frequently too late, and never fun. Our host pg has commented that more than a few dot.com failures were in part inevitable due to technical failure. I'm sure that's still the case.

[mcguire]

Frequently, it's not technical. I have in mind one individual who still maintains a project management position at a former employer, who has repeatedly made every last project management mistake possible, right down to "adding people to a late project makes it later." It got to the point where I was uninterested in his latest fiasco because it was like 1980s sitcoms---a minor variation on something that wasn't all that funny the first time around.

[ScottBurson]

I'd be interested to hear some specific examples if you care to post them.

[mcguire]

Hired a new guy who had a few years of experience, but less than most of the existing folks (most of whom, admittedly, had the same one year, over and over). He immediately starts telling us how we should be doing things. Case in question: Maven.

Now, Maven is a nice enough tool and he's probably right in that it is the new "industry standard", but it doesn't do anything that we need to do better than Ant. (Making it easy to add new dependencies to a project, in particular, is something that I anti-want to do.) The only advantage, as far as I can see, would be to allow the new guy to use an IDE other than Eclipse. The costs are pretty large, though. It was an uphill struggle to get the cowboys to use any build system instead of Eclipse's export. This would be a new build system, a new project layout, and either we could convert everything, which exactly no one had time to do (and did I mention the one year of experience thing?) or just add Maven to the already gigantic ball of mud.

Carefully explaining all of that, plus the point that futzing around with build systems did nothing to help us get stuff out the door, which is what we were having problems with and what we hired him to do, led only to blank looks and his decision to "demonstrate the advantages" in the project he was working on---exactly the reason we have a ball-of-mud problem.