Tuesday, November 24, 2015

Discomfort of defects

Last week, I was testing yet another new feature. And testing of it was very straighforward. First I tested to learn what the feature could do with simple data. Then I extended the data, and extended the variation I could bring in with the new feature. I made a few checklists to cover through relevant scenarios. It was about a day of work, nothing major.

I found 10 issues. That too is a very typical number. But what was atypical was that this time, probably because of business priority of the feature, all the bugs got fixed within one day.

As I was going through the fixes based on code commits and Jira notes, I noticed an interesting phenomenon. Only 1 out of the 10 issues I had raised had a comment. And the only comment was to say that I had found something that was _relevant_  - a mistake in how the code had been written.

There were 10 changes, so I would argue there were 10 items. But the developer, working towards no faults in his code, dismissed the other 9 and focused on the 1 as his personal feedback.

This again reminded me on how differently we think. For me, all 10 were relevant for the end user, and I really did not care whose fault it is that those exist. The developer worked against the idea that just-in-case he would ever need to defend himself, 9 of them were "new information he did not have when implementing the feature" and that he "had only one code defect".

We haven't classified things for anything but unfinished work for over a year, and still the culture of looking for one's own responsibility remains. There was no complaint on the other bugs, but the feeling can be seen in the comments - what gets acknowledged as "my bug" and what is just work on the list.