Is it a bug or a feature?

If you do development for long enough large enough team you will find yourself asking this question. It matters because you need to make decisions about what gets fixed in the current release and what only gets fixed in the next release. In other words, what should be part of version 1.0.1 and what should in version 2.0. Additionally, there is also a school of thought which says that bugs should always be fixed before new features are added. Which is great, but this assumes you actually know what a bug is.

So what is a bug and how does it differ from a feature?

What is a bug depends on who you talk to. To a developer, a bug is a mistake. To tell a developer that there is a bug in their code is to tell the developer that he be screwed up. This can lead to all sorts of unfortunate confusion between end users, QA and the developer. In reality no one (except possibly the developer) actually cares whether or not it's a particular individual's a mistake. What people care about is whether or not the program is working in a way that makes sense. For example, if an application gets out of large knife and stabs the user in the eye when they select "Copy" from the "Edit" menu it doesn't really matter if the developer intentionally programmed it to do that. What matters is the behavior is undesirable. Well, I presume the behavior is undesirable. You might actually be trying to create an application that stabs the user in the eye whenever they select Copy from the Edit menu. I don't presume to know what crazy project you're actually working on.

QA, for instance, will tend to think of any stupid behavior as a bug. For example, let's say that QA files a bug that the font sizes too small to be readable. The developer takes a look at what font size should be, double checks to see that he's using the right size and then simply claim that it's not a bug. Presumably he then goes on to stab QA in the eye.

Sale and marketing are even more out there. They have no idea how anything actually works and as a result can consider six man years worth of work to be a bug. For example, if the email client you're building doesn't do SMTP autentication then that's a bug. It's a bug because it doesn't work with this particular SMTP server. I mean come on! What were you thinking?

At Intelerad, we've gotten fed up with discussions on whether something is a bug or a feature and started thinking about everything as change requests. Once you're looking at everything as a bunch of change requests you can start focusing on the things that actually matter about those change requests and use that criteria to make decisions.

What are we trying to encapsulate when we ask if something is a bug or feature? It may matter because you made a policy that says that bugs can get fixed on existing branches or releases would features will always be fixed along the trunk. Okay, but why did you make the decision that only bugs get fixed along batches? Did you make the assumption that bugs would simply be things that were easy and quick to fix? If that's the case then why don't you say that only change requests that are easy and quick to fix get fixed along branches. Did you make the assumption that bugs would be severe; that they would stop the user from being able to use some feature of the application? If that's the case then why don't you say that only change requests that affect critical functionality will get fixed along branches. Did you make the assumption that feature work would be too destabilizing along the stable branch? If that's the case then why don't you say that only change requests that are not destabilizing will get fixed along branches. Don't say that he will only fix bugs be precise about which aspects of the change requests will allow you to fix an issue along an existing branch.

Here are the things we typically consider:

How bad is the problem?
Would the fix destabilize the old version?
How long does it take to fix?

The first two questions are the most important. The last question is more of a sanity check. If the answer to the last question is anything more than about a day, then you're probably lying to yourself about it not destabilizing anything. It should also go on the trunk because it represents significant development.

I'm making the assumption that you've already discovered that you should be working along the trunk by default. Ideally you shouldn't be back porting anything. You should be releasing major versions often enough that your clients (or users) can wait until the next major version. If they can't wait until the next version you're not releasing often enough. That's pretty much a golden rule. The length of your release cycles should be matched with the expectations and demands of your client base.