Developer optimization redux

| 1 Comment

Users are crucial to open source projects. Without them we have no reason to release publicly, and without refreshing the ranks of developers with users who join the fold, our projects die. Users are our customers, and we can't afford to treat them poorly. When a user wants to go the extra mile to help us as developers, turning him or her away is a grave misstep.

Here's an example. Andrea discovers a problem in PHP's database handling, where calling a certain function incorrectly causes a segfault. The bug isn't a work-stopper for her, and the fix is simple: Call the function correctly. Still, it's a segfault, and she figures the PHP folks will want to know about it. It also doesn't help her confidence in the tool that calling a function incorrectly segfaults. Being a good open source citizen, she decides to report the bug.

She's already spent the time figuring out the problem, and she reduces the code to a single, repeatable example, that shows exactly how to make the code segfault. "This should help them track it down," she thinks. She's spent an hour on this detour in the middle of a project for work, but knows that open source relies on bug reports to get things fixed.

She dutifully checks, and finds nothing that matches, so she goes to submit the bug. Unfortunately, the PHP site will only accept bugs against 5.2.6, instead of 5.2.5 that she is running. This leaves her with three choices:

  • Upgrade to 5.2.6 on a test machine, and test out her problem. She knows not to upgrade a production box so cavalierly.
  • Find someone using a similar install to see if that person will test it for her.
  • Submit the bug against 5.2.6, effectively lying but not spending any more of her time.
  • Throw up her hands and say "Screw it, I've got work to do."

That's what happened to me, "Andrea", the other day. I wrote about it in a frothier Perlbuzz article the other day. I wish that my frustrations with PHP hadn't overshadowed my point about community building, so I'm trying again here.

What about the users?

My frustration in PHP's approach, and they're certainly not the only community to do this, is that the emphasis is in optimizing the time of the PHP developer who has to deal with bugs. "Who wants to deal with bugs that have already been fixed?" goes the logic. I imagine someone setting up the PHP bug database saying "We need to put something up to make sure that we don't get annoyed by bugs that have already been fixed." I can understand that motivation. As someone who answers questions in #perl about WWW::Mechanize all day, I can certainly empathize with not wanting to deal with pointless comments.

And yet...

Nowhere do I see any discussion of how the user sees the interaction. I doubt anyone considered the reaction of the user who is told "Sorry, you're not able to submit your bug report that you worked to get together to send to us." Instead, debate about the original article is from the point of view of the beleaguered developer, having to deal with those darn users, contributing their bug fixes.

Yes, I understand that plenty of people submit bugs that aren't bugs, or that have already been fixed. Perl's bug reporting system is wide open, and I've closed my share of tickets in RT that weren't really bugs. But I'm OK with that.

How long does it take to close tickets that aren't right? Compare that cost to the cost of losing a valid bug report. Or worse, alienating a potential friend of your project.

In everything we do when working on projects, we need to remember there are real users, real people at the other end that are the core of what we do.

1 Comment

Hi Andy,

A great revisit on the topic, and I hope my comments here are perceived as constructive because I sincerely mean them to be.

I find it somewhat ironic that, in my opinion, the best articles on perlbuzz center around a project's public facing view while Perl in general has a very hostile facade for new users.

I love perl, and think it is one of the most powerful languages out there. Trying to come in from a new user's perspective is difficult. There is no concise tutorials or getting started guides that seem to truly make sense.

Most of the sites are just ugly and plain, one simple step up the ladder from Gopher.

As an example I frequently use, if you go to and try to figure out how to get started you're not met with anything but a lot of links.

If you click the "learn" link it tries to sell you books. That's bad, as it increases the barrier to entry. Most of the other languages make an earnest effort to teach when you click the "learn" link, rather than sell you something.

Additionally, there is no explanation as to what CPAN is which is a shame. We perl hackers tout that as our greatest public facing achievement.

Finally, if you do click over to the manual (and lets face it, no new users want to read a manual to get started) you're met with a formatted Pod reference guide.

Reference guides are not for newcomers into a language, and even though 'perldoc perl' has a tutorial section it is far from helpful. Just comparing that tutorial to virtually any language makes perl pale in comparison, which is the opposite view.

I've been harping on this for quite some time to anybody who will listen and thought I'd post it here since I feel it pairs nicely with your article above. I always worry what brilliant minds are being alienated from the perl community because of the mindset we're old, crufty and the language is accurately represented by the websites promoting perl (with the exception of perlbuzz, thank you Movable Type!)

Leave a comment

Job hunting for programmers

Land the Tech Job You Love, Andy Lester's guide to job hunting for programmers and other technical professionals, is available in PDF, ePub and .mobi formats, all DRM-free, as well as good old-fashioned paper.