5 mins or 30 mins, that's the question...

The week before this one, I commuted to work by train and got inspired for this blog.
So what's the story?

The last couple of weeks our national public transport train company - apparently- had loads of trouble keeping to their timetable (and IMHO still do but that is another story). Every single day for the past weeks the train has been delayed for 5 minutes and that made me 'tweet' the following:

"I find it more annoying to have a 5 min delay every day than to have 30 mins delay once in a while. "

and after that :

"I guess my last tweet about train travel, could very well apply to software testing too??" and "What do you think: Less annoying to have a huge bug once in a while, than numerous ones almost constantly"


I got the following responses:

@santhoshst : "True - I related it to Performance Quality criteria :) #softwaretesting

@santhoshst : "Depends on the context :)

@jahoving : "but even more annoying to have no bugs at all ;-)

@eddybruin : " 1 huge bug is better manageable than 100's of inconvenient little bugs"


There are not many replies, but all replies have something that made me think about this statement more. I have put down some thoughts/ questions that I had and would love you to respond on that!

- No bugs at all can mean a couple of things (amongst others): 1. the utopious perfect programmer has arrived to program the utopious perfect analyst's and designer's work. 2. you have not tested the right part of the software, are not performing the right tests or have automated your tests and this only checks things leaving the really important bugs unfound.

- It's annoying to get bug reports constantly. It's better to report once in a set time than to come running over to the programmer/ manager (etc.) with every single bug found. Also the 'huge bug-rule' can apply here; a huge bug can be reported immediately (it probably has to be fixed with high priority too) but all those little ones? Report it once a couple of days; else it will interrupt the programmers work (and attention) unnecessarily. It will also cloud a managers view; when you come to him constantly with every bug: the really important ones will not seem as important as they really are (famous fable of 'Peter and the Wolfe')

- When looking at performance issues. When you have - for example- a 7 seconds delay at every request this can be seen as not a big issue (in the margin) but a 1 minute delay is seen as problem. As a user 7 seconds can seem like a eternity when your on a deadline especially when you have 100's of request to work through every day. A minute delay once in a while can give you some coffee time; 7 seconds each request is simply a pain in the ...

- Of course the context has to be taken in consideration, as mentioned by santhoshst. Numerous bugs can also be very 'dangerous' when they are in a critical part of a system; even the smaller ones.

- I wondered if this one would be true: 1 bug is better manageable than 100's of little ones. I could think of a bug that had a very complex background: to get it solved it took a lot of time, management, politics and redesigning. In the same time at least 20 others with minor priority where fixed and closed. Overview can be complex for a lot of smaller ones, but it's the real big ones that can push your skill-limits. This is - mind- also related to the role and tasks you have within your organization. When this is only to report the bug and retest it when it's fixed, than the statement could well be true. When you also have to 'guide' the defect through the rework process it will probably be more like described earlier.

- When the timetable of the train at station X would be adjusted to 5 mins later, there wouldn't be a defect/bug. I wonder why they don't do this, because at the next station there is a - almost - ten minutes wait till the train leaves from there. So there is margin to set the time of departure at station X a bit later. And here comes (I know a bit unconventional) statement. Specifications can be changed to 'solve' a bug (dependent on the context/severity etc.).

I'm very anxious to see your replies. I so love discussions! and - needless to say-... please reply in one big one instead of lot's of smaller ones :-)