CoolBeans: From College to Industry

It doesn't stop there....

the bug priorities will be changing every minute. So there will be enough work for PMs everyday to work on this task.

Hey, don't blame PM...many of us were actually developers and we are well aware of how bugs are handled. Believe me we really do think 'Fix It' or 'Punt'...you think we like trying to convince people that bugs are important when we could care less!

Actually, blame some PM :-) I encounter this every day..playing bug pass the parcel is never fun. Triaging  bugs (the process where PMs, dev and test decide which bugs will and won't make it into a product before release)is often a game of who can shout loudest (and no, I'm not joking!) I don't know of a better way to do this process, test would always want every bug fixed, PMs would want all bugs which affect thier feature fixed (and could care less about others) and devs only want to fix 'interesting' bugs e.g., easy to fix, high impact or ones that let you blame someone you don't like! I've been in Office a few years and have (oddly) done all three jobs...and don't even get me started on robo-testers!

I don't think we place blame on any one discipline for the many ways we categorize and classify and prioritize bugs. The problem itself stems from the fact that everyone cares about this bug which they found (Test), fixed (Dev), or affects their feature (PM).

To me, bugs are a measure of an unknown amount of work that needs to be done to make the product shippable along with an unknown amount of destabilization. From this perspective, prioritization is just a matter of asking the question, "How much does this hurt?"

Our tolerance for pain goes up at the end of the cycle, and the question eventually becomes: "Does this bug hurt enough to prevent us from shipping this beta or release of the product? Does it invalidate the reasons we are shipping the product/prevent us from getting good feedback on this beta?"

At the very end of the cycle, the question ultimately becomes: "We've spent $X Billion to produce the suite of products that we promised to ship in Y weeks. Is this pain so great that it will *force* us to recall this product/DVDs/Media, etc, and lose $Z Million?"

After N days/weeks of being in a state where there are no bugs found which satisfy the worst criteria (Escrow), we RTM/ship. I bring all of this up because I think that the priority of the bug is deeply related to when the bug was found and what stage the product is at, and what you are comparing it against. For example, when the bar is high, pri 2 bugs are cut. You can make comparisons from the perspective of "Is the worst pri 2 bug as bad as the least-bad pri 1 bug?" The process gets the most interesting at the end of the cycle in triage.

Well, I believe a developer who is working on the same code can identify which bug can fix quickly. Some times,  PM assigned me one most highest priority bug to fix me in one day ... and I did in one hour ... as some times ... very low priority bug took too much time than expected (bcz I was not the actual person who wrote this code :S ) ...

I was asked “How do I fix more bugs?” The answer is to own buggier areas! Devs who own buggy areas (best