Actually, this reminds me of something I heard a preacher say, “before I give a sermon, I go through it, find everything clever, and take it out” (I paraphrase, not having a reference on hand).

In as much as sermons and code should both be ego-free communications of ideas, I think this is sound advice for hackers.

It is in the best interests of everyone, distributions, projects, and users, for changes made downstream to make their way back upstream. In order for that to work, there must be a commitment by downstream entities—typically distributions, but sometimes users—to push their changes upstream. By the same token, projects must actively encourage that kind of activity by helping patch proposals and proposers along. First and foremost, of course, it must be absolutely clear where such communications should take place.

What we can do to make it easier for vendors to ship the next version of our software is making it clear what needs to be done before a release. That would mean: “Here’s a list with what the next release will look like, if you want to make it happen earlier, help us hacking” This could be as easy as recording this in bugzilla, marking it as “showstopper” or “required for x.y.z” and then make the query showing those entries easily accessible through, for example, a direct link.

Although I thought I understood the importance of quality, and took pride in the quality of the software we produced, I never believed that delivering defect-free software was possible. After all, everyone knows that all software has lots of bugs, right?

Well, no, not necessarily! Certainly, most experiences with today’s software quality are not encouraging. Although few people can name even one piece of software which they use that has no bugs, defect-free software is possible to create. We know it is possible, because we’re doing it.

It started with a single engineer. This engineer was consistently producing work with a defect rate more than one hundred times smaller than our other engineers. She has done so for us for over three years now. During the same time, she has produced three to five times as much code as any other engineer.

I found this so exciting that I determined to find out how she did it, and to see if we could teach our other engineers to achieve the same quality results.

Via James Gregory, Defect-free code.

A quick one for today, sparked by recent events at work. It can pretty much be summed up in this even quicker question: do you know what your program does when it’s out of resources? Out of RAM, out of disk-space, out of address-space, out of time? Computers are indeed powerful beasts these days, and there’s a bunch of people who would like you to believe that they are effectively infinitely powerful, but observing your code working with limited resources, even if those limitations are artificially imposed, can tell you a lot of things you mightn’t have known previously.

I quickly realized that my team wasn’t prioritizing for itself – but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?

Responses review the standard way to prioritise bug fixes.

1. How to Decide What Bugs to Fix When, Part 1; and
2. How to Decide What Bugs to Fix When, Part 2.

He argues that:

Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right? Wrong. I’d bet that more than half of the buggy and unreliable software you’ve ever used was that way not because the developers didn’t have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.

He describes four approaches to bug prioritising:

1. triage: sorting bugs into Must Fix, Might Fix and Won’t Fix;
2. triage with severity: adding severities of data loss, functionality difficult, or annoyance;
3. setting exit criteria: defining the minimum set of “must do” goals; and
4. early planning based on previous experience.

Karl Fogel’s Producing Open Source Software: How to Run a Successful Free Software Project book has some guidelines:

Most open source projects have settled on approximately the same set of steps to handle this conflict between openness and secrecy, based on the these basic guidelines:

1. Don’t talk about the bug publicly until a fix is available; then supply the fix at exactly the same moment you announce the bug.
2. Come up with that fix as fast as you can—especially if someone outside the project reported the bug, because then you know there’s at least one person outside the project who is able to exploit the vulnerability.

He goes on to detail the process of being assigned a CAN/CVE number, notifying important or particularly vulernable vendors or customers, and making a public announcement.

That’s right, this bug, which is for a security hole that was fixed two weeks ago, is not being dislosed until apparently, August 1st. Same is true for several others of the holes fixed in recent versions. That’s two weeks for distibutions that have to backport these fixes to race against black hats to see who can track down the hole in all the other changes in the new mozilla release, and respectively fix and exploit it.

And so Ubuntu has decided to backport the new mozilla versions into their releases instead of backporting fixes, while Debian stable has decided to bow out of the race. Both understandable decisions in their own contexts.