Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Saturday July 27, 2002
08:59 PM


[ #6688 ]

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:

  • Make mistakes and take the arrows once and only once
  • Learn the principles of good QA from those mistakes
  • Induce those principles into the minds of the community
  • Develop good tools to make everyone else much more productive
  • Spread the wisdom to other communities

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 Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I've never even seen a project approach the levels of organization, documentation, and reliability that standard "best practices" prescribe.

    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

    • 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 ma