Flutterby™! : coding stuff

I'm happily grinding forward at the current startup, and have no plans to change that, but two people have approached me recently with coding work. One of those wants what I think it was Frederick P. Brooks called a "language lawyer" for his group, someone that the people who write code because they have to, but aren't programmers by history, can go to for the details of why something should or shouldn't happen a specific way.

I was happy that he thought of my work in that way, but realized that I haven't been that person for quite a while. So I've been diving back into thinking about the details of stuff again, if only as a good exercise. Whence my exploration of copy constructors and increment operators.

Over at Brainwagon, Mark had some links on regular expressions that are worth following up on.

And I've only paid cursory attention to what people have said about the software development process in the past decade or so because, frankly, when Ed Yourdon was shown to be entirely loony in his response to Y2K issues it confirmed my beliefs on the credibility of the things he said in Modern Software Engineering. And most of them seemed to be a response to "tell people what they want to hear", back in the early days of my software development experience we (hi Frank and Eric!) came to the conclusion that the best thing you could do for programming productivity was give programmers doors, but in the "it's cheaper to slap them in cubicles" world, managers wanted to hear what the "agile development" evangelists were telling them.

So I've been listening to some "Extreme Programming" and "Agile Development" and "Crystal Process" (sounds more like something the FBI would be trying to crack down on) downloadable audio shows, and I'm just looking for what's going to be to this community what the exposé of the value of a PhD from San Rafael's "Columbia Pacific University" was to the self-help book genre in the late 1990s.

Man, what a bunch of telling people what they want to hear, but make it nebulous enough that you can't blame your failures on their recommendations when the project fails. And if the project succeeds (and it'll likely do so independently of whatever these practices recommend), then they can take credit.