(Reading time: 5 – 8 minutes)

Programming is fun and easy compared to keeping track of everything.

One of the things I have to keep track of is the Thesis custom_functions.php source file for my Thesis custom template pages. This file sits on the web server of course, but also in a source code repository, and in a local copy running on my development computer.

Normally, this isn’t a problem.

Then I edited custom_functions.php through the built-in WordPress file editor. I forgot that the plugin editor strips out newline escapes ("\n" → "n"), which litters the web page with random letters “n” and thoroughly destroys the layout.

Now, having multiple copies is a problem, because one of the copies is broken.

So I spent a unhappy afternoon being stymied by an “unfixable bug” in the WordPress plugin editor.

“Works for me”

I’m not the only person who has had this trouble.

But none of the WordPress developers have it.

As you can see from the screen capture of the WordPress Trac ticketing system, issue #10903 is closed with a “worksforme.”

That’s a very hackerish thing to say.

I can’t say I blame them. WordPress is free software after all. If this issue really were a problem for me, I’d knuckle down and fix it myself, or pay someone to fix it for me.

Instead, I make like the internet and route around the damage.

The No-solution Solution

The no-solution solution for fixing bugs is pretty simple. Here’s a few concrete suggestions:

1. Leverage the pain of others.

Typically, when you have a bug in a piece of software like WordPress, many other people are experiencing the same problem.

Most likely, someone has also reported the problem.

Once the problem has been reported, it goes on a release schedule for eventual fixing (or not). You have little control (none) over the release schedule, so…

2. Do something else.

For me it falls into the category of “If it don’t work, find sumpin else to do.”

In my example above, I just stopped using the built-in plugin editor. I routed around the problem. Simple.

But that’s not good enough for some people. For example, Holly Jahangiri prefers a more direct approach:

That is an entirely-too-practical approach to life, David. I gravitate towards the “if it don’t work, beat your head against a brick wall until your ears bleed and some geek takes pity on you and figures it out so you’ll stop” approach. :)

3. Bang your head until your ears bleed.

A while back, Jena Isle had a problem with one of her articles submitted to Digg. The article could be loaded from her blog, but it came back with Invalid URL from Digg. It ended in my lap via Holly Jahangiri:

…”Invalid URL” has to do with special characters in the title. In this case, there are no obvious special characters, but when you try to Digg (or strangely enough, even copy from the address bar) the URL from the post page – Bam! error.

I did some poking around on Google, and found that it was known but infrequent problem, and nobody has any idea how to fix it. Blood, leaking from my ears… I emailed Holly something like “Don’t Digg that article.” Problem solved!

Holly, to her credit, continued to bang her head:

Oh, well, it’s still working for me – that bleeding out the ears thing – except there were no geekier geeks racing to my rescue and I did figure it out, finally, I think. For some reason, somehow, it was taking the url as having a comma before blogspot (I have no idea why, unless there’s some place to set that in the plug-in Jen’s using, but I suspect maybe, just maybe, it’s some weird error somewhere in her settings). Anyway, digging it from the FRONT page, not the post page, worked.

Yikes!

If head banging isn’t your thing (and nothing wrong with it if it is), you need to know…

When to punt

Free software such as WordPress depends on users reporting and, when possible, fixing bugs. It’s a good model, as you can see from the wild success of WordPress.

Fixing, or even reporting bugs isn’t always feasible. Putting on my developer hat, when a user can’t precisely describe a bug so that I can reproduce it, I’m not going to have time to fix it. Likewise, when I don’t have to precisely describe a bug, I won’t report it either.

Here are a few guidelines I use for deciding whether to fix or report bugs:

• Do I have time? It’s going to be an hour’s work, at least. If fixing it won’t save me time in the long run, punt.
• Does Google bring back junk? We’re getting close to the day when just about any keyword or phrase with traffic is going to be gamed. If I get no related results from search, punt.
• Is the bug close to my competence level? There is this notion of a “technology stack” (which I’ll write more about in the future*). This means I’ll consider fixing bugs in WordPress, but not in the web server, etc.

NOTE: All of these guidelines apply to like activities, for example, web and WordPress theme design.

If something is just too hard to do, that’s a hint!

As a public service, here’s a recap of techniques for handling bugs:

1. Leverage the pain of others.
2. Do something else.
3. Bang your head until your ears are bleeding.

Can you add to this list? What’s your special technique for handling bugs?