I'll quickly admit to having tasted the Software Development Kool-Aid. Having worked for big companies and small companies, as well as for myself and with other free software developers, I've never even seen a project approach the levels of organization, documentation, and reliability that standard "best practices" prescribe. (Here, I'm thinking of just about everything that isn't Agile. ISO-9001 made busy work for two or three people out of 60 in the manufacturing group, and everyone else just ignored it until the auditor came around. Why would that be different with programmers?)
It is, of course, hubris to think that books, articles, and example code will make the entire culture of developers pick up better habits. I believe in peer pressure, and I believe most people do want to do things well, but I don't buy the Manifest Destiny undertones of some of the "open source" discussions. I do have several metaphors (relating the education of my particular subgroup of programmers to software testing -- my focus this past year) which seem to be writing themselves. I do plan to continue to write (oh, the plans!), because that is having some positive effects.
Looking at the state of programming in general, I see a couple of trends. There are people who program as a job, and people who program as a passion. Neither class is intrinsically immune from panic mode, where things spiral out of control. There are also people who've had training (whether formal computer science, vocational mentoring, or classes) and people who've trained themselves. I've seen mediocre code and shoddy development practices along both axes, so I won't credit formal study any more than necessary. It's not as if you have to swear to use proper encapsulation to pass your midterm.
Looking further, there are people who ought to know better and should be reminded that Quality Counts, and there are people who've never heard that things can be improved and need to be evangelized. I want to reach both groups.
This is one of those jobs that no one really wants to do, though, even if they know how. Of course, there are plenty of people who want to contribute back to their community, but don't necessarily know how. It's a good match.
The trick, as I see it, for Perl and QA is this. How do we:
One of Schwern's goals for Perl 5 QA was to work out our bugs with Perl 5 so we'd have a better idea how to handle Perl 6. I think it's time to start in on Perl 6 with vigor. Hopefully, we'll get a warm reception. (No, this entire, poorly-organized personal journal was not all just an excuse for that photo. It's a nice benefit, though.)
Yes, I have scary plans... stay tuned.
The problem with "best practices" is that they're often written by people who, with the very best of intentions, list those as best practices those things they wish they'd done, or that they wish that the people who'd actually done the work had done. Some of the practices are a good idea in practice, and some only in theory. If you gather up enough "best practices" to guide you, and try to follow them earnestly, you almost guarantee that your project will never live to ship, unless you're lucky enough to have a customer with very, very deep pockets.
Re: QA
chromatic on 2002-07-28T06:59:29
I was talking with someone who shall remain nameless (until one tiny project is approved), and used the pronoun "they" to refer to the Extreme Programming community. He picked right up on that. "Don't you consider yourself an Extreme Programmer?"
"Yes and no," I said. "It's a process of integrating the features into an existing shop. We don't do all of the practices yet, but I keep pushing ahead." It reminds me of a story.
An XP coach is talking with a project manager. "We're an XP shop," the manager proudly claims. The coach then asks how pair programming is working out.
"Oh, we don't do that."
The coach then goes on to ask about testing, refactoring, and the metaphor. It turns out that the team does none of these things. "This is odd," says the coach. "Why do you say you're doing XP?"
"For starters," says the manager, "we don't write documentation."
(I probably got that one from Ziggy, so you may have heard this one before.)
