Skip to main content

Prioritizing Software Defects

Often times we're overwhelmed by a number of critical defects that need to be fixed "ASAP". If you're using an issue tracker, you have the ability to prioritize issues but what happens if all your issues are the highest priority (blockers)?

A trick that I utilize in my work-flow is to figure out what dependencies each issue has. I ask myself the following questions for each defect assigned to me.

1) Is another teammate dependent on my fixes in order for him to get his job done?
2) Is this issue really stopping the launch? Is there a quick solution that the client is willing to go with in order to successfully launch?
3) Do I need third party support on this issue?
4) Who do I need to talk to get the necessary information to fix this issue?

From the questions above, you can really start to figure out which software defects you should be fixing first. Here's my opinion on what the queue should be:

1. Teammates come first

The issues you should resolve first are the ones that other teammates are dependent on in order for them to get their job done. A perfect example is if you're providing core functionality in a library and other developers are building components on top of your code. There will be a point where your teammates won't be able to progress as they can only do so much with limited testing.

2. Find out what information you need to fix the issue

If you find yourself scratching your head over what the client wants out of an issue; you should fetch that information ASAP. You should never have to assume functionality--always figure out what the clients' intentions are. This approach leads to less bugs sprouting from what you thought was a fix but really wasn't.

3. Third-party support has a time-limit

If you've ever had to call a support line to get help on third-party integration (cough, Liferay, cough, Omniture), you'll know that their work hours are the usual 9-5. Incidentally, this means that your time-frame to resolve integration issues is very tight. Generally, whenever you have to get support from a third-party your whole team (even the client you're working for) should assume that it can be painfully slow or inadequate. I'm not saying Omniture is bad--From my own experience, I think they have the best support: very helpful, very responsive.

4. Is it really a defect or is it a change request?

This is a big question most of the time and requires you to have some back-bone. In most cases of software development, clients will always try to ask you for extra functionality or extra features without having to pay for them. A really easy way to spot this is if they categorize the change request as a "software defect". A prime example would auto-completion on form fields when the requirements don't specify that fields have auto-completion--a client response would be, "well all fields should have auto-completion because X, Y, Z, A, B, C sites have it." It's very easy to say that but in reality it would require a significant amount of effort to implement that site-wide. Firstly, each field would need to have a data source (auto-completion suggestions), secondly testing all the fields in all browsers. Sometimes, it's just not worth it and you have to do your best to convince the client that it would eat away at the budget (development time and QA time) for such an "enhancement".


What are your thoughts on how to prioritize software defects? Project Unnamed horror stories with how defects are prioritized? Post in the comments below.


Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.
Post a Comment

Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.


World of Warcraft Ninjalist addon: version 0.1 coming along quite nicely

After toying around with more GUI related issues in World of Warcraft's API, I've decided to take a totally different direction. Originally when I architected this addon, I knew in my mind it would be a super simple Console application that a user could easily paste in a name and add it to the database; however, why stop there?

After discovering AceGUI, I can easily start developing UI components in no time! As of right now, I've got it saving data in between game sessions--the interesting part will come when I'll have to develop the web service that will parse the SavedVariable.lua, eliminate duplicate entries, as well as, do a huge merge between their copy and whats on the server's (per realm basis of course).

Here's a screen shot of the responses when adding new Ninjas to your list:
When a user clicks add after entering a name in the textbox, it'll go ahead and add that person to the ninjalist tagging the user's realm and current date/time. Someday, I…

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:

Now, whenever you make a commit, it should show up like this in the log:

Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this

Want more emojis? check out the Emoji Mardown Cheatsheet!