September 15, 2018 at 01:05Noose of fear
- Transfer
As soon as you start to be afraid of your technology, new reasons for fear will soon appear.
The fear loop tightens like this:
Fear begins when a harmless edit unexpectedly causes a problem. Downtime in production or just an annoying bug. A mistake can attract the attention of management. Nothing inspires fear like 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, a single client whose data settings are different from everyone else). Whatever the specific reason, the result is: “I did not know that this would happen.”
Several similar events - and now 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 increase, and the volume 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 moment on, the cycle of fear becomes self-sustaining. The price of even small changes continues to grow endlessly. The time required to release changes is also increasing.
This can end in three ways:
The cycle of fear begins when people perceive a technical problem as a personal one. For the first time, when a simple code change led to big and unpredictable consequences, you need to call the "technical special forces" - a team of specialists. They will determine why the system allowed this and what technical changes will help avoid this in the future.
The tribunal is the worst response to failure.
The difference between the “technical special forces” and the tribunal is how specific people approach this problem. To avoid the loop of fear, wise guidance is required. Look for people with experience in DevOps and technical project management.
Like many reinforced loops, the cycle of fear is incredibly difficult to break. So far, I have not observed a single case of successful exit from it. If it started in your company, I would love to hear about your experience!
The fear loop tightens like this:
- Minor edits lead to unpredictable, frightening, or costly consequences.
- We are beginning to fear change.
- We try to make all edits as small and local as possible.
- The code base is filled with patches, exceptions and special cases.
- Fear intensifies.
Fear begins when a harmless edit unexpectedly causes a problem. Downtime in production or just an annoying bug. A mistake can attract the attention of management. Nothing inspires fear like 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, a single client whose data settings are different from everyone else). Whatever the specific reason, the result is: “I did not know that this would happen.”
Several similar events - and now 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 increase, and the volume 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 moment on, the cycle of fear becomes self-sustaining. The price of even small changes continues to grow endlessly. The time required to release changes is also increasing.
Crucial moment
This can end in three ways:
- Cardinal code refactoring (usually with a different team) under the motto “now we will do it right !” See also: second system syndrome and “What you can never do, part I” .
- Large-scale outsourcing.
- Selling affected assets to another company.
How to avoid the loop
The cycle of fear begins when people perceive a technical problem as a personal one. For the first time, when a simple code change led to big and unpredictable consequences, you need to call the "technical special forces" - a team of specialists. They will determine why the system allowed this and what technical changes will help avoid this in the future.
The tribunal is the worst response to failure.
The difference between the “technical special forces” and the tribunal is how specific people approach this problem. To avoid the loop of fear, wise guidance is required. Look for people with experience in DevOps and technical project management.
How to break a loop
Like many reinforced loops, the cycle of fear is incredibly difficult to break. So far, I have not observed a single case of successful exit from it. If it started in your company, I would love to hear about your experience!