Monday, August 22, 2005

Where is it Cheapest to fix bugs?

While I was working with my team on the latest release of our product, we had a small percentage of reopened issues or one can say 'last minute bug discoveries'. While I was analysing the issues and trying to fix the root cause (and not the symptoms), I articulated the following important stages of adding anything to the code base (it is possible to introduce or skip bugs at any stage)
1. Issue entry (incomplete, unclear, wrong specifications leading to the wrong development and therefore the mother of all bugs i.e. useless development. In some cases, after careful analysis, we have observed that the issue is best fixed in a non development area like devliery, or sales commitments etc. No code=no bugs)
2. Issue design (Plan and details of how the issue will be tackled. The seeds for bugs are sown here, if the design is lacking clarity, simplicity, proper integration & is improperly or not reviewed by multiple people for perspectives)
3. Issue development (Bugs are introduced here, due to improper code maps, missing or incomplete dependancy charts, improper reviews, carelessness, etc)
4. QA (Bugs are missed here, due to improperly documented test cases, insufficient automation, etc)

As part of any product development model, it is imperitive to find and fix bugs as early as possible and definitely before it reaches the customer. Its a no brainer (and a mantra in software development books) that we have to move towards a right first time build. Our endevour should be to nip the bug in the first two stages where it is cheapest to fix. So to all developers, I suggest a more concentrated effort to Perform aggressive specs and design reviews with more than one person.

2 comments:

Arti Singh said...

Taking your point "Perform aggressive specs and design reviews with more than one person." ahead, just conducting reviews is not sufficient. The process if checking review effectiveness is also very important.
The person initiating the review should circulate the to-be-reviewed document and the checklist for review atleast a day prior to the review.
The people who are a part of the group review should go through the to-be-reviewed document before coming for the review, this does not waste every one elses time.

After conducting couple of reviews like this analyze whether the team was actually able to catch defects during the document review, this will reveal the review effectiveness of the reviewers.

Anonymous said...

I would like to exchange links with your site suniluttam.blogspot.com
Is this possible?