Bugs, in an awful lot of organisations they're a four letter word, they just shouldn't happen. But unfortunately despite the shouting and stomping, they still will.

your software has bugs

Your software has bugs, go ahead, say it, try it on. Does it scare you? It doesn't scare me. I know mine does, this isn't a shock, revelation or epiphany for me. I had that years ago:

One dark stormy night with a start I sat bolt upright and realised I wasn't perfect, that I couldn't write perfect code. I sat through the rain and the thunder awake and frightened, but as the sun broke the next morning it a clear new day dawned on a world washed free of it's sins. I felt renewed, rejuvenated; I bounded to the office, spearheaded an overhaul of our development process, got a more agile workflow implemented with fast iterations and complete management support.

Ok, it wasn't quite like that. I was actually up all night because someone somewhere had been freaking out about yet another bug the day before. It was affecting one user, and it would only be a matter of time before it would be affecting others - then like dominoes all of them; soon they'd be the rats leaving our sinking ship upstream and they'd take the paddles with them - in short: DOOM!

It's very easy to find a bug, say it's obvious and should have been tested, it's quite another to test all the functionality and find all of the bugs before launch. My software has bugs, so does yours and everyone else too.

get over it and stop blaming others for your problems

Bugs are a result of code, written by programmers- but it's not always just the programmers who are to blame. Organisational pressures leading to scope and feature creep, poor design and processes or a lack of any sort of roadmap will all contribute to the problem.

So many times I've been working to a deadline (beginning, middle or end - it doesn't really matter once a timeline is fixed any changes will incur a cost), then someone comes along and starts a sentence with "What about..." and totally blows the schedule. The problem is people rarely take into account the very simple fact that the schedule wasn't set to include this new task, or the next next one.

This schedule pressure then leads to rushing either the design, the testing, the coding or all of them - this more or less ensures there will be more bugs.

Common excuses I hear for this are:

• It's obvious, and should have been thought of. Sometimes this is a valid comment, but I have never been part of a team where the obvious was actually missed. In my experience this has almost always been used as some rhetorical comment to excuse someone for not mentioning a feature until launch or later.

• If we don't have that for Friday's launch, we won't get customer X

• Adding would mean getting so many more customers This is such a great trap for a business- so good I'll be writing much more about it in the future. Oftentimes it's political or the result of an organisation without any clear goal setting or planning.

Schedule pressure is often further exacerbated by not making any allowances for bugs. If you don't make allowances for fixing them post launch, you've already missed your next deadline.

what can we actually do about them?

There are a few things we can do organisationally and individually to lessen their impact. Start by not being afraid of them, accept they're a fact of life and get over it. Shit happens, and it piles up - get a shovel or get out of the way. Look to the processes and people and streamline the development workflow. Everyone involved needs to think things through. Finally once you've accepted bugs, worked to minimised them in development deal with them calmly and rationally, if at all.

deal with the workflow issues

If your development processes seem to be creating a lot of bugs, they're the fist place to look. These are going to be the hardest to change, but they'll also give you the biggest returns. A few of simple steps to take:

• Design the interfaces first Changes to desgin mid-stream cost at any stage of the cycle, but the earlier they're discovered the less of an impact it will have. At least wireframing your interfaces means everyone gets a good look at them before development starts, and can say "what about..." early.

• Remember changes cost When someone asks for a change, make sure you point out that changes will affect delivery. Ask them why it wasn't thought of earlier. Don't take anything as read and make sure nobody else does either.

• Iterate often Small quick iterations mean features go into use quickly and mean less changed code and less places for bugs to hide. This also allows bugs to form part of the next iterations work.

all bugs are not created equal

Not all bugs will affect people equally. Minor display issues are not as important as an issue where user data is randomly disappearing. An issue where the front page of your website is full of gibberish is far more important that a newsletter not being sent on time.

All bugs should enter a triage system, where the scope of the problem is analysed and a prioritisation decision is taken. There is no room for rhetoric, blame or politics in this process and clear descriptions of the problems are key. The title of this post is verbatim the subject line from quite a few emails I've seen in my life, the body is usually not much more helpful and generally descends into politics and conflict. A minor display issue affecting some users is hardly "irreparably damaging", "actionable", cause for anyone to "seek any and all legal recourses for reimbursement or compensation" or cause to run off and offer the person our most heart felt and abject apologies for the inconvenience.

We need to step back, look at the extent of the problem and respond appropriately. Going off on one while a wild wacky tale to tell alter, isn't really professional or productive.

Which leads us to...

not all bugs need to be fixed immediately, or even at all

In a perfect world, we'd fix every bug as soon as it was reported. Then again, the world wouldn't be so perfect because we've got a bug in our code... in a slightly more perfect, yet undeniably imperfect world we'd like to fix bugs as soon as they happen. This isn't always going to be possible and for various reasons it may not make sense to fix a bug immediately.

Take for example the following completely hypothetical situation. You've got a bug in some obscure import routine written for one customer a year and a half ago. The sales team promised it was going to be the next big thing, would open the door on a whole raft of customers that used that package - it turned out to be just the one and they may or may not renew their contract in six months time. Politics aside, given certain situations the import fails and you might choose to just not fix the bug

• They're unlikely to renew and fixing it isn't going to sway them or get you any new customers Don't fix it and just remove the whole broken import from a future iteration. Chalk it up to learning and plan new features better so you're addressing the needs of your users

• A work around exists Your time might be better spent elsewhere, especially if the problem only affects a single or small number of customers

• Planned developments will obsolete the feature A reworking of the feature, section or other areas of your website, the integration of a new API or a new workflow or way of doing things may mean the bug just dissapears in a future revision. One caution with this, as with any bug fix the promise should be delivered to the cusqtomer on time