According to Scott Hanselman and a Slashdot discussion many organizations have adopted FDD - Fear Driven Development. So what is FDD? Is it some new development approach that just appeared recently? Is it a new name for a development practice that existed before? The term was defined by Jason Nocks back in 2008:
- Characterizes 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 artifacts, before producing any actual working software. In essence, being so afraid of making mistakes that you end up not producing anything at all.
- Characterizes a software development process that attempts to wring productivity out of its participants by instilling in them fear of losing their jobs.
FDD is typically a product of Fear Culture:
A Fear Culture is one in which all employees are afraid to show the product of the work because they feel threatened in that they might be fired. A common response to perceived errors or mistakes is to find the (ir)responsible people and fire them. This is supposed to let other workers know that they are not allowed to make mistakes. The result is that workers are so afraid to make mistakes that they hide whatever they produce. Whatever they do must not be known by others because any perceived failure will be considered a reason for termination.
According to Keith Sader, fear culture is an ultimate anti pattern:
In the FearCulture, processes are supposed to shield the company from the people.
Scott Hanselman discusses several main aspects of FDD:
- Organizational fear
Organizational fear can have developers worried about making mistakes, breaking the build, or causing bugs that the organization … creates excessive process, and effectively stands in the way of writing code.
- Fear of losing your job
Other kind of Fear Driven Development is when an organization tries to get developers to stay far too late, work unreasonably hard, by implying that they'll lose their job at the sign of any problems with the project. Threatening jobs will never create a more productive team. It only perpetuates negative feelings and will always lead to people quitting.
- Fear of changing code
Another kind of Fear Driven Development is when your development organization (or your entire organization) is afraid of the code. Perhaps the code is older (legacy code) but more likely it's just not fully understood. It mostly works, but folks are afraid that a small change to the code could cost unpredictable side-effects.
Hanselman’s post and Slashdot discussion created quite an activity of responses by people describing additional fear factors, for example:
- Kijana Woodard:
Fear of the unknown [that] leads to over-engineering. It's quite a curious occurrence to mix poor planning and over-engineering. It sounds impossible, but it results from focusing on the wrong things
- Taki Stewart:
Fear of not meeting the estimate - Sometimes senior management will reprimand or punish when work takes too long so instead the Dev team will bloat their estimates to ridiculous proportions
- Unknown developer:
Fear that if you don't do the important tasks yourself the biggest idiot on the team will get hold of them and create immense damage.
And the list goes on.
It seems like even in the shops with relatively good development culture "fear-driven development" and its cousin worry driven development tend to appear whenever stress levels get higher. Pressure makes people take questionable decisions that they think are "safe".
