Once you begin to fear your technology, you will shortly have cause to fear it even more.
The Fear Cycle goes like this:
- Small changes have unpredictable, scary, or costly results.
- We begin to fear making changes.
- We try to make every change as small and local as possible.
- The code base accumulates warts, knobs, and special cases.
- Fear intensifies.
Fear starts when an innocuous change goes badly. Maybe a production outage results, or maybe just an embarrassing bug. It may be a bug that gets upper management attention. Nothing instills fear like an executive committee meeting about your code defect!
This sphincter-shrinker originated because a developer couldn't predict all the ramifications of a change. Maybe the test suite was inadequate. Or there are special cases that are only observed in production. (E.g., that one particular customer whose data setup is different than everyone else.) Whatever the specific cause, the general result is, "I didn't know that would happen."
Add a few of these events into the company lore and you'll find that developers and project managers become loath to touch anything outside their narrow scope. They seek local safety.
The trouble with local safety is that it requires kludges. The code base will inevitably deteriorate as pressure for larger changes and broader refactoring builds without release.
The vicious cycle is completed when one of those local kludges is responsible for someone else's "What? I didn't know that!" moment. At this point, the fear cycle is self-sustaining. The cost of even small changes will continue to increase without limit. The time needed to get changes released will increase as well.
Breaking Point
One of several things will happen:
- A big bang rewrite (usually with a different team.) The focus will be "this time, we do it right!" See also: second system syndrome, Things You Should Never Do, Part I.
- Large scale outsourcing.
- Sell off the damaged assets to another company.
Avoiding the Cycle
The fear cycle starts when people treat a technical problem as a personal one. The first time a seemingly simple change causes a large and unpredictable effect, you need to convene a technical SWAT team to determine why the system allowed it to happen and what technical changes can avoid it in the future.
The worst response to a negative event is a tribunal.
Sadly, the difference between a technical SWAT team and a tribunal is mostly in how the individuals in that group approach the issue. Wise leadership is required to avoid the fear cycle. Look to people with experience in operations or technical management.
Breaking the Cycle
Like many reinforcing loops in an organization, the fear cycle is wickedly hard to break. So far, I have not observed any instance of a company successfully breaking out of it. If you have, I would be very interested to hear your experiences!