Broken Windows, Broken Projects

Better Software Magazine
Volume-Issue: 
2010-04
Summary:

A social experiment in the ‘80s found “Vandalism can occur anywhere once communal barriers are lowered by actions that seem to signal that 'no one cares.'" The same can be said for our software projects.

In March 1982, The Atlantic magazine ran an article titled “Broken Windows” by George L. Kelling and James Q. Wilson. [1] The authors of this now famous article wrote, “So­cial psychologists and police officers agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken.” One broken window, left unrepaired, is a signal that the building is abandoned and that no one cares, so breaking more windows means nothing. The authors continue, “Vandalism can occur anywhere once communal bar­riers—the sense of mutual regard and the obligations of civility—are lowered by actions that seem to signal that ‘no one cares.’”

To test this theory, Philip Zimbardo, a Stanford psychology professor, had an automobile without license plates parked with its hood raised on a street in the Bronx. Within ten minutes of its “abandonment,” the car was at­tacked and stripped. First, the battery and radiator were removed, and within twenty-four hours almost everything of value had been taken. Random destruction then began with the smashing of win­dows and the ripping of upholstery. Within a few more hours, the car had been turned upside down and totally destroyed.

To test the claim that this behavior could “occur any­where,” Zimbardo performed the same experiment in sedate Palo Alto, California. This car fared somewhat better, re­maining untouched for more than a week. Then, Zimbardo hit the car with a sledgehammer and within a few hours, this car also was looted, turned upside down, and destroyed.

To put the broken windows theory to the test, Kelling was hired as a consultant by the New York City Transit Authority. The subway system was cleaned—specifically targeting graf­fiti removal. In 1990, William Bratton, an admirer of Kelling, took over the Transit Police and implemented a zero-toler­ance for fare dodging and easier processing of those arrested. These strategies, among others, became part of Mayor Rudy Giuliani’s “quality of life” initiative. [2] Was it effective? A later study of crime trends in New York City showed the rates of both petty and serious crime fell suddenly and significantly after these actions were instituted.

Most of us have experienced our fair share of project broken windows: impossible deadlines, shipping a product filled with disaster-in-waiting defects just to meet an arbitrary schedule, firing the tester for finding too many defects, bogus incentive schemes, declaring a project “done” when it’s not and phony-ing up documents to prove it, and the ever-pop­ular adding more people to a late project.

Windows get broken on every project. However, it’s vital not to let them remain broken for long, as the price can be high if they are ignored. To paraphrase Kelling and Wilson’s statement: A violation of trust, left for a time, is a signal that the project has been abandoned, that no one cares, and so violating additional trust means nothing. Once the sense of mutual regard, obligations of civility, and trust are lowered by actions that signal that no one cares, why should anyone continue to care? All it takes is one broken window—the project man­ager imposes an unrealistic schedule; analysts skip the details of requirements in an extremely com­plex part of the system; designers and developers ignore fu­ture system needs for different parameters, data, algorithms, languages, or hardware devices; testers just focus on creating large numbers of tests rather than creating effective tests; users pay cursory attention to acceptance testing. When it be­comes clear that no one cares then, quickly, no one cares.

A key tool for repairing broken windows is trust. Trust comes from integrity—a steadfast adherence to a strict

File: 
AttachmentSize
Broken Windows, Broken Projects273.52 KB

About the author

Lee Copeland's picture
Lee Copeland

Lee Copeland has more than thirty years of experience in the field of software development and testing. He has worked as a programmer, development director, process improvement leader, and consultant. Based on his experience, Lee has developed and taught a number of training courses focusing on software testing and development issues. Lee is the managing technical editor for Better Software magazine, a regular columnist for StickyMinds.com, and the author of A Practitioner's Guide to Software Test Design. Contact Lee at lcopeland@sqe.com.

Upcoming Events