Yesterday I asked my first question at beta.stackoverflow.com, the new developer community put together by Jeff Atwood and Joel Spolsky. The question was: how do you enforce or maintain the quality of the bug reports in your bug tracker.

A common problem is low quality bug reports, perhaps one-liners, PEBKACs, or bugs that don’t contain enough information to reproduce. I’ve seen emails from developers go out complaining about this and how difficult it is to navigate around in the bug tracker because of this, and it seems it’s a common problem.

The root cause might be a lack of understanding of the development process by the bug reporters, or perhaps just laziness, but all bug trackers seem to eventually contain a large degree of low-quality bugs.

At one project I worked on, which to be honest wasn’t huge, we grew tired of all the weird bugs in our tracker, and had what we called a bug deathmatch - we bought lots of candy, booked a meeting room for an hour and a half (which is the time limit for productive meetings), gathered the entire team (which in this case was 4 developers and one QA engineer) and went through as many bugs as we could, either marking them invalid or assigning them to a developer. After we did this over three Fridays, we were done with all of the bugs.

I was a little skeptical at first, but it actually went really well, and we got rid of all of the low quality bugs. If you’re going to try to duplicate this though, you’ll need a quick thinking person to hold the meeting and make decisions. The problem is that if you spend too much time discussing a bug report, the team will grow tired, and you’ll spend too much time on this. The concept is to efficiently judge bugs based on the information in the bug report and the collective intelligence of the team. It’s important to keep the pace up when going through the bugs, if necessary marking them to be analyzed further by a developer, just to get it out of the way and move on to the next bug.

It worked really well, but I’ve only tried this once, and my feeling is that it depends a lot of the team.

As for the question on stackoverflow - someone has yet to answer anything groundbreaking, but I’ll let you know.

If you haven’t read anything by Ted Dziuba yet, go do it now. For a while he ran a blog called Uncov, where he covered Web 2.0 ideas and startups with humor and sarcasm that was razor sharp. Then he started his own Web 2.0 company that isn’t all that, but his writing is still good (he’s got his own column at The Register).

In his latest essay in his column, titled Hadoop: When grownups do open source, he writes about the differences between people that get things done and those who dabble in the programming language fad of the week. The essay is worth reading, and he is dead on.

The essence of the essay is this: shit is hard. Or things, if you like. Writing a fully functional system for distributed processing and storage (like Hadoop) is complicated and takes a lot of intelligence and effort. And you don’t choose the tool that is popular this week to do it, you choose something with wide industry like Java.

While I was reading the essay, I was reminded how Paul Graham writes in his book, Hackers & Painters, that there’s money in boring stuff because not many people want to work on it. So if you’re looking for a business idea that will survive, perhaps you should think of a boring and complicated project… The latter being optional, only include it if you’re smart. ;)

If your idead is boring, then you’ll get a head start since people won’t make the effort of doing the same thing until they see there’s money in it … enough money to make up for it being boring. And then if it’s complicated you’ll have a wider head start, since you have gained more domain knowledge. Too bad if they’re smarter than you, though - and someone always is.

The XHTML Basic 1.1 recommendation was published by the World Wide Web Consortium (W3C) on Tuesday this week, but no one seems to care. I was a little puzzled, so I tried to find out why…

It turns out that XHTML Basic is a document type that has the minimal set of modules (as per the modularization of XHTML), in addition to a few other basic things. It is “designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes.” Wait, what?

Is this the 90s? Don’t users expect the full web experience on their mobile phone or settop box? Granted, it might be a problem putting a browser on a pager (anyone still use that?), but why bother? Sure, I guess creating a fully compliant browser can be difficult, but there is one company that has made one that is installed on such different devices as the Nintendo Wii and barcode scanners.

There really is no excuse to give users of mobile phones or settop boxes a subpar browsing experience, and any specification that supports that myth makes me sad…