Free Range Development

For years I’ve used a method of categorizing software defects that has panned out pretty well.  We categorize based on when an issue has to be fixed, all things considered:

• Urgent:  It must be fixed in the next internal build.  If it isn’t fixed, we don’t have a build.
• High:  It must be fixed in the next public build.  Public is anything going beyond the development team, even if it’s just over to the guys in Marketing, or QA, or whatever the next team is that receives software from the development team.
• Medium:  We’d really like it to be fixed in the next release, and for sure by the next major release.
• Low:  It doesn’t matter when it’s fixed.  It may never be fixed, even if it’s still technically an open defect.

We got to this method of categorization because it seems to work for any issue, and across team boundaries because it really is based on the net importance of an issue to the goals of the company.  For example, if you have a spelling error that must be fixed before you do your next release, it can’t be a Low.  It’s probably a High.  A data corruption problem that happens on Windows 2000 SP 3 quad processors with less than 128MB of RAM is technically a defect, but is probably a Low.

In short, you look at each item and say “If this was the only thing, would I hold the release for this?  The next build?  For the most part, this really reduced friction within the development team and the company management in general because everyone could get their head around why something had the priority it did and during release closeout time it became a lot easier to adjust priorities.  We’d look at each high and urgent item and ask would we hold up the next commercial release for this one thing? No?  Medium it is.

Over time a long list of medium and low issues would accrue that were items that just weren’t worth addressing right now.  Perhaps they had easy workarounds or were in corners of the application or just had too little return for the effort of changing them.  Whenever I look at this list there are always a couple of them that hurt - they’re little things that may be really important to me personally but I know I couldn’t justify them at the expense of a cool new feature or something higher on the list.

Defect Closing Day

What we like to do every once in a while is give the team a time boxed period - like two days - where the whole goal is just to close as many issues as possible.  We don’t care how meritorious they are, it’s really just about fixing the ones you want to fix.  You can even document a defect just to fix it and run up the score.  It doesn’t matter - it’s just about polishing the parts you feel polishing.

I like to do this at spots in the development cycle for a release when we know we aren’t going to make big changes and there’s a little slack in the schedule.   Perhaps we’re waiting on beta feedback  or we just did a big release and don’t want to stray too far in case a critical issue crops up.  Either way, it’s an opportunity for each developer to scratch the itch they want to the most.

We’ve been doing a little bit of this on Gibraltar:  We’re working towards a major release that will incorporate some big picture features people are going to love, and while we’re waiting for feedback on the latest private beta we didn’t want to rock the boat.  So we’ve been picking off the little things that annoy us personally.   In my case there are a few nits that come up every so often in conversation and while everyone agrees they are low priority I’m just tired of hearing about them - so fixed they are.  (Example:  Deleting a large number of sessions is slower than it could be because the user interface is trying to refresh as the data is changing.  Now Fixed.)

In the end, I’d like to believe that the fine point care and feeding we put into the product will reflect in your enjoyment of it.  There are a host of tiny little details that we couldn’t possibly get into during a customer demo (or even the documentation) that are there to make your life easier as you gain experience with Gibraltar. (hint:  try right clicking in the various grids.  Ten to one, if you want to do something  you’ll discover a neat option on the action menu that gets it done).  A lot of the inspiration for these neat little ideas comes from when we aren’t developing on the headline feature of a release but are just looking around for little things to polish up.

Customers are Urgent

If you’re a Gibraltar customer and report an issue, you get to set the priority.  If it’s important to you and it’s a defect you can bet not only will it be fixed in our next build, but we’ll work to do a release of that fix as fast as possible.  We’ve done a lot internally to automate our build and validation processes to make it easy for us to address your concerns quickly without creating new problems.  Frankly, even if you tell us it’s no big deal I can virtually guarantee that we’ll treat it as urgent, because the whole point of what we do is to help you support and delight your customers.

If you haven’t had the chance to work with us yet, give it a try - you’ll be impressed at how well we listen and how committed we are to helping you get the most out of our vision for Gibraltar.