January 19, 2009 at 23:27About broken windows.
Scientists have found that behind the fence with a sign "Do not enter! Do not fasten bicycles! ” all the same, 27% of those who want to cut the path are included, but if you fasten your bike nearby, the number will increase to 82%.
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 violates established norms much more often if he sees that someone has already violated them before him. If dirty walls, uncleaned garbage, or a broken window appear in the courtyard, drunk companies, abandoned cars, gop-stoppers, and so on will be attracted to them like a magnet. To avoid this, it is necessary to strangle small violations in the bud.
I had a chance to work on a rather large project, whose code quality was very lame. There were no internal standards, the level of performers varied greatly. The quagmire of general apathy sucked me pretty quickly, and I went with the flow, blurting out the code anyhow, as well as planting new bugs during the fix of the old ones. Dates in the company were constantly breaking down, not a single milestone on time gave up.
After some time, personnel shifts took place, and under my supervision was a group of five such apathetic programmers. The front of the work was outlined to me, and the swamp in front of me began to play with new shades of despondency, for lead was regularly received on the head for failure to meet deadlines. But fortunately, it was then that one colleague told me about this theory. And here are the conclusions I made from it:
Apathetic programmers didn’t like it much. Some tasks were wrapped up two to three times.
Some had to be fired (fortunately, I had such authority), and to recruit new ones. Refactoring of the old swamp lasted about a year, sometimes gradually, sometimes by completely rewriting part of the functionality from scratch (think very carefully before doing this!). The result is an architecturally slender module, with a clear, intuitive interface, and an understandable implementation. The level of programming in the department has grown, people have learned not to make blunders.
At the department level, this approach worked wonderfully. Unfortunately, other departments continued to work according to the old scheme. They endured “Eccentricities” about the review of their changes in our code, but they themselves chose to work in the old way. The search for bugs in their code dampened very much and every failure of a milestone was now perceived not as routine, but "we did everything, and because of them again the file". In general, after a couple of years, I changed my job, having failed to plant culture in the whole company, which is sad. Nevertheless, I hope that my experience will help others survive in such companies and even change them for the better :)
UPD: article about experiments with the “Broken Window Theory”
UPD 2: Illustration from cruel_clown and Liksys
What is this, 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 violates established norms much more often if he sees that someone has already violated them before him. If dirty walls, uncleaned garbage, or a broken window appear in the courtyard, drunk companies, abandoned cars, gop-stoppers, and so on will be attracted to them like a magnet. To avoid this, it is necessary to strangle small violations in the bud.
How does this relate to IT?
I had a chance to work on a rather large project, whose code quality was very lame. There were no internal standards, the level of performers varied greatly. The quagmire of general apathy sucked me pretty quickly, and I went with the flow, blurting out the code anyhow, as well as planting new bugs during the fix of the old ones. Dates in the company were constantly breaking down, not a single milestone on time gave up.
After some time, personnel shifts took place, and under my supervision was a group of five such apathetic programmers. The front of the work was outlined to me, and the swamp in front of me began to play with new shades of despondency, for lead was regularly received on the head for failure to meet deadlines. But fortunately, it was then that one colleague told me about this theory. And here are the conclusions I made from it:
- The development of my department was allocated in a separate module.
- All work with the rest of the product was directed through regulated interfaces.
- A hard standard code was introduced in the department.
- All tasks began to go through a mandatory code review.
- All changes from other departments were necessarily monitored and reviewed.
Apathetic programmers didn’t like it much. Some tasks were wrapped up two to three times.
Some had to be fired (fortunately, I had such authority), and to recruit new ones. Refactoring of the old swamp lasted about a year, sometimes gradually, sometimes by completely rewriting part of the functionality from scratch (think very carefully before doing this!). The result is an architecturally slender module, with a clear, intuitive 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 wonderfully. Unfortunately, other departments continued to work according to the old scheme. They endured “Eccentricities” about the review of their changes in our code, but they themselves chose to work in the old way. The search for bugs in their code dampened very much and every failure of a milestone was now perceived not as routine, but "we did everything, and because of them again the file". In general, after a couple of years, I changed my job, having failed to plant culture in the whole company, which is sad. Nevertheless, I hope that my experience will help others survive in such companies and even change them for the better :)
UPD: article about experiments with the “Broken Window Theory”
UPD 2: Illustration from cruel_clown and Liksys