Broken windows

Once, researchers set out to find out the reasons why, in some areas of the city, among the nearby buildings, some remain well-kept, while others turn into abandoned and dark ruins. The results of these studies led to the emergence of a theory of the effect of broken windows.

According to this theory, the appearance of at least one broken window, which is not replaced during a sufficiently long period of time (say, more than one or two weeks), creates a high probability that the next window will soon be broken, and then another one (and so on) that ultimately leads to the abandonment of the entire building.

Even those people who would never have broken the window of a well-kept building, may well take and throw a stone into the window of a building, in which there are already many broken windows.

Employees or residents of this building have a feeling of abandonment. They cease to monitor its purity, they begin to litter. When a building becomes sufficiently abandoned, those who inhabited it leave it. Such a building can become a place where bums gather.
')
In one experiment, an unused vehicle stood untouched for several months. But as soon as one window was broken, the car was disassembled in parts in hours and turned upside down.

Also to this theory can be attributed to the appearance of garbage on the streets. When a person sees that there is garbage lying around, it is much easier for him to throw something else away than wait for a meeting with the bin.

Using this theory, the police in New York began to actively suppress even minor manifestations of illegality (for example, graffiti on the walls) to avoid major ones.

Generally speaking, this theory can be applied to a huge number of aspects of our life.

How does this relate to programming?

Directly. If you leave “broken windows” in the design of the application or in the code itself, the programmers have thoughts like “The system is written carelessly when writing the following code in my head. If I write this piece of code carelessly, it won't get any worse. ” I witnessed a similar thinking with myself and with a large number of other programmers. As a result, the system turns into a cluster of carelessly-written code, and the situation only worsens with time.

Most often, this leads to the fact that the team leaves, leaving behind a code that terrifies the next generations of programmers, who, in turn, either offer to rewrite all the code, or, if that failed, do not stay up in this company and rather retire soon

To rewrite the code in a very neglected case is the only way out. It is possible that it should not be rewritten completely and from scratch, but the gradual rewriting can correct the situation for the better. Otherwise, the project will eventually turn into an abandoned block of code (unless, of course, the project is not “one-time”).

By the way, more often than not, management seems to prevent such a seemingly necessary, rectification of the situation. Here is an example of their judgment: “all programmers are ready to criticize the code of previous programmers and / or always bring it to the ideal.”

Correction of the situation with time becomes only more expensive: the more code is written, the more it will be rewritten and tested. Therefore, it is preferable to restore the “broken windows” as soon as they are noticed, rather than bring to rewriting the code.

In addition, a self-respecting intelligent programmer seeking development will not work on a project that slides straight down due to the destruction of “broken windows” because of the resulting sense of degradation. (Most often, it’s not just a sensation, and even if it’s not degradation, it’s definitely not development.) At the same time, mediocre programmers don’t care about the quality of the code. As a result of the fact that intelligent programmers leave, and the mediocre remain, the formed team will consist of these most mediocre programmers.

A common mistake made by management is to assume that it is the “weak” programmers who cannot withstand the work on such projects, which they leave behind, and the rest - the “strong” ones. But in fact, more often than not, everything is just the opposite.

What to do?

Do not leave "broken windows" in the project. Having met them, immediately take some action to correct them. Even inaction in this case can lead to very unpleasant consequences.

Sources

• Wikipedia: Fixing Broken Windows (photo from the same place);
• The Pragmatic Programmer: From Journeyman to Master ;
• Own experience and knowledge.