August 21, 2010 at 11:38 am
Comments posted to this topic are about the item Rating Bugs
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
August 22, 2010 at 10:19 pm
Hello!
I have been working in a Sustenance team for the last 6 or so years - ever since the product was only supporting SQL 2000 SP3. Over the years we have refined our bug/defect prioritization methods such that all bugs/defects are classified into 3 different dimensions - which are a combination of:
1. Product Severity
2. Technical Severity
3. Customer Severity
A weighted rating is then developed and bugs/defects are tackled according to the same.
In our case with the Michigan state map being in the wrong shape, the product severity might be low to medium, techical severity might be medium and customer severity might be high - which might end up targetting a fix for this somewhere in the next 2 cumulative hotfixes (and might not be able to wait for the next service pack).
I am sure that MS is using an even better, and sound rating methodology, and would definitely like to hear about the same. However, the way the team should be split (according to me) is that the most complex bugs pass amongst team members in a round robbin fashion (i.e. Bug# 1 goes to team member# 1 and so on) with a time-line on them, while the medium priority ones lie in a pool. As Developers get bored or feel the need for a change, they might switch tracks and get a few easy wins, and you rightly mentioned.
Have a good day, everyone!
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 22, 2010 at 11:56 pm
I fully agree with Nakul about the planning and distribution of bugs among developers. I unfortunately do not have the luxury of having other developers with me other than my boss. I have a different way of priopritising of fixing bugs. If I have a.critical bug that will take me long to fix and another less critical bug that will be quick, I will tackle the quick bug first and then not having to worry about the other bug spend all my time fixing the critical bug that will take me long.
Fortunately, unlike Microsoft for instance, because we are a small business, I do not have so many bugs and normally my bugs is smaller than theirs.
:w00t::w00t::w00t::w00t::w00t::w00t:
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
August 23, 2010 at 2:03 am
I tend to agree with Nakul in thinking that the customer's perception of a bug should be considered in the prioritisation process. If it is a minor problem but hundreds of people are reporting it, you can please hundreds of people by fixing it.
The other thing is, if your volume if hi-priority bugs is stopping you working on the lesser ones, you might need to review your classification strategy. You really should spend most time fixing the minor ones, work you can drop to attend to the (hopefully few) urgent ones.
The bugs we work on are prioritised, and each priority has a different Service Level Agreement (SLA). Providing we resolve each one within its SLA, we can work on them in whichever order we like. We also do change work, which is lower priority than attending to live issues and is a useful filler at quiet times. It's about being busy enough to keep your job and not so busy that you lose your sanity.
Being UK-based, the Michigan bug could lie undiscovered on our systems for many years!
John Riley
Logica
August 23, 2010 at 2:46 am
Hello!
I think John raised a very good point by mentioning that "Being UK-based, the Michigan bug could lie undiscovered on our systems for many years!". That brings the customer's geography also into consideration (the geography can be the geography of the customer, or the customer's customer).
Allow me to explain - if an organization outside of the US is a 100% Export Oriented Unit (EOU) and deals with business mostly in the US, then this might be an important issue. However, for a localized organization, this might not be a big deal.
When prioritizing, if your product is truly international, the customer spread might also influence a decision on the issue's priority (eg. issues reported from expanding markets might trump everything else in some cases, while in other cases, increasing competition might force the team to work on issues reported from the home ground).
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 23, 2010 at 2:53 am
Protecting reputation is extremely important. The michigan example reminds me of an incident a couple of years ago where EUROSTAT, the European institution charged with providing statistics about everything, issued a document with a map of Europe on the cover, from which the country Wales was inexplicably missing. (Indeed it appeared to have sunk!)
Such incidents, while at first sight of no 'incidence', can in fact enormously affect the credibility of an organisation, and as such must be addressed urgently.
I recall losing faith in my GPS (satnav) when, on reading through my manual, I can across a diagram where the manufacturer had inadvertantly inversed East and West on a compass. I changed to a rival's offering soon afterwards.
August 23, 2010 at 6:50 am
The US auto industry is still based in Michigan, last I checked. I would think this would have a high priority for a fix.
In my experience, perception is weighted very heavily in the prioritization of maintenance response. In my company, dashboards have a very high visibility, with visitors being shown our latest dashboard innovations on a nearly weekly basis.
But in our situation, I would think we would discover something like this long before rollout.
August 23, 2010 at 9:53 am
Steve Cullen (8/23/2010)
The US auto industry is still based in Michigan, last I checked. I would think this would have a high priority for a fix.In my experience, perception is weighted very heavily in the prioritization of maintenance response. In my company, dashboards have a very high visibility, with visitors being shown our latest dashboard innovations on a nearly weekly basis.
But in our situation, I would think we would discover something like this long before rollout.
I worked for WordPerfect in the early nineties, Ford Motor Company was one of our largest customers and remember that features they wanted and bugs that effected them were always the highest priorities to fix. If this had been an issue in our product it would of been fixed before the product was released since Ford is in Michigan and they would have caught it in Beta.
Is this a big enough issue to fix for Microsoft? I guess it depends on who uses this feature and how much sway they have. The squeaky wheel gets the grease.
---------------------------------------------------------------------
Use Full Links:
KB Article from Microsoft on how to ask a question on a Forum
August 23, 2010 at 2:19 pm
This issue is one that has always bothered me. I wanted to devote a small amount of time every week to fixing small annoying bugs, instead of working on the high priority bugs or new features all the time. I think Red Gate suffers from this with some of their products, SQL Prompt as an example, in that small bugs that seem like they would be simple to fix don't seem to get any attention, even after major updates.
Of course you could end up working the small bugs all the time and never getting to the big ones or new features, so as always "It depend." and you have to try to come to a balance that works good for you as well as your customers.
August 24, 2010 at 10:37 am
An assessment of the bug should be split out amongst the team. Ease of fix, impact, time to fix should all be included. If the bug is simple enough and can be corrected without downtime and fit into the schedule - then go ahead and treat it. It all comes down to the assessment.
Users / clients will also have a bit to say about magnitude of the bug too. If their perception is that it is absolutely much more important to fix a decimal place than to fix the mathematical operation - that is partly their choice.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 24, 2010 at 11:32 am
Triage and prioritization seem the most logical however there will always be disagreement as to what is the correct mix and/or outcome or the process.
I maintain the 'purist' point of view ...
A bug is a bug is a bug - fix it !
As an example, take buffer overflows - just try to count how many of these type of fixes have occurred over the last decade all over the software universe. All of these could have been stopped by simple parameter checking had it been designed in ! Granted, some came from 'legacy' code reuse, open source or proprietary. Somebody just grabbed it for 'reuse' and there we are all over again.
Better yet, design and code more completely from the start in order to stop propagating the same issues.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
August 25, 2010 at 9:35 am
UMG Developer (8/23/2010)
I think Red Gate suffers from this with some of their products, SQL Prompt as an example, in that small bugs that seem like they would be simple to fix don't seem to get any attention, even after major updates.
We do try to fix bugs on a continuous basis and make frequent 'private' releases available via our forums. Eventually these are rolled up into public point releases and pushed out via our Check for Updates feature. Some bugs appear to be outwardly simple to fix, but are in fact far trickier than first appearances. We will try to tackle these on a case by case basis, prioritising based on the number of customer reports.
We've just released the first early access build of SQL Prompt 5, described further on our forums:
http://www.red-gate.com/MessageBoard/viewtopic.php?t=11683
Kind regards,
David Atkinson
Product Manager
Red Gate Software
August 25, 2010 at 9:38 am
@david-2, thanks for the update from RG.
@Rudy - I think that is nice, but not always practical. There is limited time, and at some point you have to decide what do you ship and when. Waiting to patch until all bugs are fixed is impractical, so you prioritize, make fixes, move some stuff into new versions.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
August 25, 2010 at 9:42 am
Hello!
I believe the rating of bugs is very much linked to a previous editorial that ran on SSC about scoping features & bugs for a new release.
Scoping is indeed very tricky and because it is determined by multiple technical and non-technical aspects, the process might end up pushing out a few bugs/features to further down the list.
On the whole, I agree that a bug is a bug and must be fixed. While there are multiple ways to assign a weight to it, the time when it must be fixed is determined by Product management - and is not something that should be left to us developers. A bug might not be important to work on if the entire feature is anyway going to be redesigned in the next release that's just around the corner.
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
August 25, 2010 at 11:29 am
Steve, the difference between 'practicality' and 'purist' seems like an insurmountable chasm.
However, until we reach a shift in the ways we think about 'bugs' as I had mentioned earlier, this chasm will never be bridged !
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply