What do you after you find a bug ?

 Technology  No Responses »
Sep 052009
 

‘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?

 Posted by Rajiv Narula at 10:15 pm  Tagged with: , ,

Uncle Bob, Professionalism and TDD

 Technology  2 Responses »
Feb 272009
 

The other day I saw a presentation at infoQ by Robert Martin (aka Uncle bob) on professionalism and ethics.

He gave a very colorful presentation on vast ranging topics on professionalism and software development.

His driving point was we as software professionals are ultimately responsible for what we deliver and that is code. There can be no valid excuse for sloppy work. It’s too easy to take refuge in tight deadlines and unreasonable managers.

I am also reading a book by him- Clean code , after Horea recommended to me. Though I have just read the first chapter so far- that seems to be  a promising read

One thing that didn’t resonate well with me was Robert’s views was on TDD.  I fully appreciate the benefits of Unit testing framework- but I found it difficult to reconcile with TDD as he explained it

As he explained- TDD has three laws

1) Do not write production code for which you do not have a unit test

2) Write only enough Unit test as is sufficient to fail the production code. And then stop.

3) Write enough Production code to pass the unit test. And then stop.

So as per this.. when you start coding on clean slate- you can’t start with Production code  (See rule #1) and so you start with Unit test- as soon as you write  a single line invoking production code which doesn’t even exist yet- you are done (Rule #2 kicks in at this point). In fact at this point you will get a compilation error !!! Now you move to Production code and write that class- then you stop- because you have satisfied the Unit test. See rule #3.

So practically – if you follow this discipline- you will be alternating between Production code and Unit test- like 30 seconds each. At any point you will write only few line of code at a  time- Production or Unit test

Whew !!!. This sounds extreme to me. Way too extreme actually.

These are my problems with TDD

1) How do you test for possible bugs in Unit tests ? write more Tests for that ?

2) The developer who coded a bug in Production code- why won’t he not introduce a similar bug  in Unit test

3) Unit testing is important- but how do you define that unit. Do we define each line as a unit- because that’s what we seem to be trying to do. I disagree that each and every line of code needs to be unit tested. Units can be more granule than a line of code

I think Unit tests are an excellent resource for preventing breakages and regressions and come in very handy especially before and after undertaking a  re-factoring exercise.

And then I came across another interview at InfoQ- . Now Luke Francl is speaking closer to what I think

He basically says that Unit testing is not end all means of software quality. He stresses a great deal on code reviews by peers, usability tests.

Oh well. I haven’t ever used strict TDD ever. Maybe some day…

 Posted by Rajiv Narula at 7:31 pm  Tagged with: ,
© 2011 Technology Cafe Suffusion theme by Sayontan Sinha