Fear Driven Development

‘Fear Driven Development’ (FDD) is a term, which I have come across recently in a discussion with colleagues about the impact a zero mistake tolerance culture can have on a team of software developers. The term was likely coined in 2014 by Scott Hanselmann (https://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx) and by Marcus Biel (https://marcus-biel.com/fear-driven-development/). In the following article I provide a summary of my findings on FDD.

What is FDD?

FDD is generally characterized as a software development process that attempts to forestall mistakes during coding by moving at a snail's pace, producing, double-checking, and re-triple-checking lots of paper artefacts, before producing any actual working software. In essence, being so afraid of making mistakes that you end up not producing anything at all or certainly not producing anything, which is effective, efficient and easy to maintain. In other descriptions, FDD is characterized as a software development process that attempts to wring productivity out of its participants by instilling in them fear of losing their jobs. In a FDD culture, most developers will leave the code as is, not daring to reformat, restructure, or fix even the most minute issues. They’ll just do the bare minimum.

What causes the fear?

The FEAR in FDD can have different causes or drivers. In a lot of cases I have been able to observe, it is instilled by the organization that the developers are part of itself. Here the culture of the organization and the management style play an important role. Especially big organizations have a tendency to administrate any innovation (and writing code should always be innovation) to death with a strong focus on paper and creating excessive processes. The continuous political infighting often present in such places means, that decisions are only made painstakingly slow or not at all, always adhering to the principle of ‘too little too late’.

These ‘organizational’ factors form the basis for the actual spread of fear, which is mostly driven by the management and the culture of an organization. A culture of ‘zero-tolerance’ which is sometimes accompanied by an insulting and humiliating behavior of the management, will get any developer worried about making mistakes, tarnishing his or her reputation or even loosing the job. Behaviors like unwillingness to share information, parochialism, micromanagement or implying that everyone can be replaced will only increase the fear and can cause a cloud of anxiety to loom over the organization. Poor planning, inability to decide and resource constraints fueled by this make bad things even worse.

In such organizations you will often find the ‘Hero Culture’ very much alive. Anyone who stays later than the others is a hero. On a ‘Hero Culture’ project, everyone stays late. The project manager stays until 10 PM and is back at his desk the next day at 8 AM. All the underlings are expected to arrive before the manager and leave later than the boss. When the deadline is near, people are expected to work even harder. Eventually all will look like walking (or sitting) dead. Somehow still alive but actually more looking like a corpse. Needless to say that such behavior will never create a more productive team.  It only perpetuates negative feelings and will always lead to people quitting.

Another kind of FDD is when the development organization is afraid of the code. Maybe the code is old legacy code or it is just not fully understood. It mostly works, but everyone is afraid that even only a small change to the code could cause unpredictable side effects. So better not to touch it at all or if that can not be avoided, build the new code on top of the existing one without even trying to integrate it properly. Newly introduced IF THEN statements at the beginning or the end of existing code, for example, can be a symptom of FDD.

What are the consequences of FDD?

I have touched on a lot of consequences FDD can have above already. No results at all or too little results too late and too expensive. A negative culture at the workplace, low staff morale and burning out highly qualified developers.

The one consequence I have always been able to observe is that FDD stifles innovation. Developers working in a FDD culture will stop to innovate. This is bad for the developers as it reduces their opportunities to learn and hinders their personal development. But it is also negative for the organization as the ability to innovate is a critical success factor in today’s fast changing technology world.

For the developers, there is hope, they can always look for a new challenge in a FDD-free environment. If you cannot change it, leave it. The organizations they will leave behind either change their ways or they will be at risk of eventually failing because of their lack of innovation.