About broken windows.

Scientists have found that behind the fence with a sign "Do not enter! Bicycles do not fasten! ”Still includes 27% of those who want to cut off the path, but if the bike is fastened next to it, the number will increase to 82%.

What is it, doctor?

This is a special case of the behavior described in 1982 by James Wilson and George Killing in the article "Broken Window". The fact is that a person more often violates the established norms, if he sees that someone has already violated them before him. If dirty walls, uncleaned garbage, or a broken window appear in the courtyard, drunken companies, abandoned cars, gop-stoppers, and so on will be attracted to them like a magnet. To avoid this, it is necessary to nip in the bud minor violations.

How does this relate to IT?

I happened to work on a fairly large project that had a very poor quality code. There were no internal standards, the level of performers was very different. The quagmire of universal apathy sucked me pretty quickly, and I swam with the flow, blinking the code like any other and planting new bugs while fixing old ones. The deadlines in the company were constantly breaking down, not one Mailstone did not give up on time.
After a while, personnel changes took place, and under my command was a group of five similarly apathetic programmers. I was outlined the scope of work, and the swamp in front of me began to play with new shades of gloom, because the leaders were regularly received on the head for disrupting the deadlines. But fortunately, it was then that a colleague told me about this theory. And what conclusions did I draw from it:

• The development of my department was allocated in a separate module.
• All work with the rest of the product was directed through the regulated interfaces.
• A hard code standard was introduced in the department.
• All tasks began to pass the mandatory code review.
• All changes from other departments were necessarily monitored and reviewed.

Apathetic programmers did not like this much. Some tasks were wrapped two or three times.
Some had to be fired (fortunately, I had such authority), and recruit new ones. Refactoring of an old swamp lasted about a year, sometimes gradually, sometimes completely rewriting a part of the functionality from scratch (think very well before doing this!). The result was an architecturally slim module, with a clear, understandable interface, and an understandable implementation. The level of programming in the department has grown, people have learned not to make blunders.
')

But not everything is so fabulous.

At the department level, this approach worked great. Unfortunately, other departments continued to work according to the old scheme. They tolerated "eccentricities" about the review of their changes in our code, but they themselves preferred to work in the old manner. The search for bugs in their code very much discouraged and every breakdown of Milestone was no longer perceived as routine, but “we did everything, but because of them again the file”. In general, after a couple of years, I changed jobs, and having failed to implant culture in the whole company, which is sad. Nevertheless, I hope that my experience will help others to survive in such companies and even change them for the better :)

UPD: an article about experiments with "Broken Window Theory"

UPD 2: Illustration by cruel_clown and Liksys