For this blog post I’ll use the word bug referring to either a fault/error/failure.
Jorge Aranda and Gina Venolia wrote a paper called The Secret life of Bugs. (click here if you want to read it)In general it talks about how even simple bugs are very complicated to track with just automation, mostly because the human factor.
It’s very funny
painful how sometimes when I work on a project, 40% of the time is dedicated to develop a functionality and the rest fixing the secondary effects. If this effect is a bug then I write an issue either on the repository or anything related to the project management. But here is the trick, as humans we believe we can keep track of everything in our minds, but in my experience I have seen a typical scenario:
(I | He | She | They | We ) will write about the bug later or in the next sprintSomething that will be fixed very late or never.
The authors Jorge and Gina have proof of why we can’t fully rely on electronic repositories a 100%. Which is mainly related to coordination problems.
Do we always record the necessary information to understand the whole story of the bug?
According to their studies the researched bugs databases had the next problems:
- Some bugs in the records are not bugs in strict sense.
- Some bugs have duplicate records
- Some bugs exhibit symptoms that are initially seen as different bugs and recorded separately
- Some bugs do not always die when they are marked as closed
- Some bugs basic field in the records are incorrect
- Some bugs have wrong status.
- Some life of bugs will never be understood without a face to face or personal investigation.
So in the end it is really interesting to see how when they tried to see the track of the life of the bug they reached dead ends. Or found that histories omitted important details of the bug. I believe our social human factor is the key to why we can’t trust 100% information extracted from electronic repositories.