‘What do you do after you find a bug ?- I asked a team-mate one day while we were having lunch.
‘Fix it’ came the quick reply, with out a pause.
‘No. No. I mean after you fix it’
‘Go home’ and then he quickly added – ‘ after fixing other bugs’ , now begining to look perplexed.
‘I mean , how do you…follow-up ? Do you revisit your unit test cases (if you have any in the first place), or do you talk to QA team to see ow they found it ? ‘ I clarified, having clearly understood that lunch is not a good time for such conversations.
‘Ah ! Well, I do that yeah- Sure helps’ He replied, nodding his head wisely.
By this time I knew that this was not getting anywhere- so I turned the topic to iPhone.
This is what my problem is.
I obsess over bugs. I am not satisfied just that they have been fixed. I need to know more.
How did it miss unit testing ?
Do the test cases cover them ? Do we need more test cases ?
Is it an indication of more defects that are yet to be discovered ?
Why didn’t the QA team discover them in the last iteration or before ?
Did we miss something in deployment ?
And on and on…
I guess this is a reflection of my underlying belief in my sub-conscience that all defects are mistakes, And mistakes by definition can be avoided. Only if certain actions had been done, the outcome could have been different. Only if…
But are they ? Are they really mistakes? Or are they just a natural part of development process ?
I guess I could argue either way…
My first instinct is to probe to find how we missed the defect and then identify what part of the process broke. And then go and plaster it with another counter process. Conceptually this will ensure that the defect doesn’t happen again and we will slowly tread towards a zero-defect software. Hmmm it can’t be that simple – can it be?
The problem is that we have just now put another layer of a process and mind you- these processes don’t come at zero-cost either. Processes need effort to be defined and maintained and then fixed when they break(just like defects !). I don’t think we should automatically head towards putting a new process every time we see a problem. Sometimes just talking about the problem makes it go away. But if it doesn’t and you have a repeat pattern- then go ahead and do something about it.
And then we also need to keep in mind that software development is a very human activity. There are somethings which you can control (Set up a daily integration build) and some that you can’t (Non work related personal problems). Also splitting hair for each and every problem can cause un-needed stress on all the parties involved. But then sometimes, it is needed- definitely.
To take a dig @ TDD- if you practise TDD religiously, you can have no bugs in the Production code. All your defects will be in the test cases- which can ‘t be that bad- eh?