As soon as you begin to fear your technology, new reasons for fear will soon appear.

A noose of fear drags on:

1. Minor edits have unpredictable, frightening, or costly consequences.
2. We are becoming afraid of change.
3. We try to make all edits as small and local as possible.
4. The code base is filled with patches, exceptions and special cases.
5. Fear intensifies.

Fear begins when a harmless edit unexpectedly causes a problem. Downtime in production or just an annoying bug. The error may attract the attention of management. Nothing is more frightening than a meeting of directors about your defect in the code!
')
There was such a hassle, because the developer could not predict all the consequences of the change. Perhaps the test suite was insufficient. Or a special case has surfaced that is observed only in production. (For example, the only client whose data settings differ from all others). Whatever the specific reason, the result is: “I did not know that this would happen.”

Several such events - and now the developers and project managers do not want to touch anything outside their narrow sphere. They hide their heads in the sand, like ostriches.

The problem is that this behavior will have consequences. Inevitably, the code base will begin to deteriorate, the need for major changes will grow, and the amount of refactoring in builds without release will increase.

The vicious circle closes when one of these ostriches becomes the culprit of someone else's bug. From this point on, the cycle of fear becomes self-sustaining. The price of even small changes continues to grow without end. The time it takes to release changes is also increasing.

Crucial moment

This can result in three ways:

1. Cardinal code refactoring (usually with a different team) under the motto “now we will do it right !” See also: second system syndrome and “What should never be done, part I” .
2. Large-scale outsourcing.
3. Selling the affected assets of another company.

How to avoid a loop

The cycle of fear begins when people perceive a technical problem as personal. The first time, when a simple code change led to large and unpredictable consequences, you need to call the "technical special forces" - a team of specialists. They will determine why the system has allowed it and what technical changes will help to avoid this in the future.

The Tribunal is the worst reaction to failure.

The difference between the “technical special forces” and the tribunal is how specific people approach this problem. To avoid a loop of fear, wise leadership is required. Look for people with experience in DevOps and technical project management.

How to break the loop

Like many loops with reinforcements, the cycle of fear is incredibly difficult to break. So far, I have not seen a single successful exit from it. If it started in your company, you would love to hear about your experience!