Broken window theory and quality Martin Jansson
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.
Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.
based on an article titled “Broken Windows” by James Q. Wilson and George L. Kelling in March 1982. You can find a bit more about the background here.
It is my belief that the same thing happens with products and product development. When bugs start to accumulate in an area and where the bugs do not get fixed, you will as a tester lower your standard on what is a bug or not by comparing the new found ones to the vast amount that already exist. Eventually you might get the feeling that you might not even bother reporting bugs, because you know that they won’t get fixed anyhow.
I think this is mainly a managerial problem. Examples of these kinds of problems can be when…
- focus is on implementing new features, just getting them in there
- covering an area with tests is more important than actually finding bugs and getting them fixed
- the threshold for getting a bug fixed in the late stages of a project requires earth quakes or miracles
Many other testers talk about this phenomena as when products are going rotten or something similar.
How serious is this problem for testers? What do you think?
It is a good analogy and I think that you are right that this is a managerial problem. But we should remember that sometimes the manager has based decisions upon lousy testing!
To answer your question, I do not think that this is a serious problem for me as a tester.
If the product has become rotten there is probably a reason for that, and there are plenty of factors that could play role in these cases (and it is probably not because I had done a bad job).
How I deal with such situations (and not get too invested in order for it to become a problem) is to investigate what priority and attention the product has, which guides me to how much effort I should put in at all. There is no need to put too much effort in a project/product that is about to sink due to mismanagement.
On the other hand, I think it is sad when products that don’t deserve it become rotten. But I guess that it is more a problem for me as a human than as a tester.
I have experienced a difference being a consultant vs. being perm worker. As a consultant it was easier to look at product, state that it was rotten, then move on. While as a perm worker you understood that this was the product that I will use every day for a long, long time and eventually become depressed by it.
Kees Keiser and colleagues investigated this experimentally at the University of Groningen. Paper are at http://www.ppsw.rug.nl/~lindenb/documents/articles/2008_Keizer_Lindenberg_Steg_The%20spreading_of_disorder_Science_Express.pdf
Their fascinating experimental results broadly match Wilson and Kelling’s position in their ‘Atlantic’ article; when a rule (even an arbitrary rule) is seen to have been broken, people are more likely to break other rules.
It’s a short (but not a trivial) jump to equate rule-breaking with bugs. If you take that jump then there is plenty of relevance for us as testers – and for us as managers, developers, users and team members.
However, if the idea leads someone to shift responsibility for quality onto management or another anonymous representation, then I think that person has made a mistake. If we can accept that pride in our work tilts us to do better work, we should also accept that we could allow ourselves to work less carefully on a sub-standard product.
Lots more about this in “The Irrational Tester” – http://www.workroom-productions.com/papers/The%20Irrational%20Tester%20v1-06.pdf
Note: I’ve just released the next version of the paper, but can’t put it on the server yet. Email me for a copy. Cheers – James
@Eventually you might get the feeling that you might not even bother reporting bugs, because you know that they won’t get fixed anyhow.
I am currently facing a similar situation wherein inspite of testing the product overtime and filing the defects, the management is simply not
interested in getting the bugs fixed. There are 2 problems to it:
1. Mentality of the Management which is more interested in getting the product out with minimal features and charge a bomb to the customer if the customer comes back with new requirements (or even work on new products/projects)
2. Testing team which fails to provide adequate information about the impact that some bugs might have on the product if shipped to the customer.
Ideally, as testers, we should be giving all the quality related information about the bugs, the risks that are associated with the bugs and the impact that it can have in the customer’s production environment. Rest is left for the management to decide. As testers, we can only facilitate quality related information.
The idea of exhaustively testing the product and finding bugs without expecting them to befixed is a very hard feeling as a tester. However, I think that we need to do bug advocacy for critical bugs to be fixed if not all. Getting emotionally bound to the bugs that are filed will only harm the testers in terms of de-motivation for further testing assignments.
Happy Testing,
Parimala Shankaraiah
http://curioustester.blogspot.com
@James, I will sink my teeth into that article and go through your paper. Regarding “I think this is mainly a managerial problem”, perhaps it should be rephrased to “In many situations it is a managerial problem.” cause I agree that it is easy put the blame there and there can be so many factors.
@Parimala, I think we need to work on our propagande skills when talking about the bugs to management. Sometimes it takes guerilla thinking to get what you want.
It would be interesting to identify things that we can do to not get to the “rotten product” situation. I am sure that in many situations it is not just the product that is rotten, but whole departments, the company culture and so on. I think Lister & DeMarco has listed a few of these things in Peopleware, if I’m not mistaken.
[…] And in some way, this meant that a high score indicated that the product was taken care of (see Broken window theory and quality). While this might have been true, we were ever so wrong with the idea on capturing the Product […]