Fear Driven Development - FDD

I had an interesting chat recently at a conference in the "hallway track." The hallway track is all the great conversations that happen in the hallway between sessions.

What drives your development processes? Are you a TDD house, where your tests drive development? Or, perhaps there's a chief architect who isn't a very nice person. We call this ADD - Asshole Driven Development. However, this chat was about FDD - Fear Driven Development.

Organizational Fear

Organization fear can have developers worried about making mistakes, breaking the build, or causing bugs that the organization increases focus on making paper, creating excessive process, and effectively standing in the way of writing code.

This "analysis paralysis" slows the entire project down. Every one is so afraid of the process that forward motion stops. There's a great post called "10 ways to lose a team" that covers many negative behaviors that can affect a team. Things like

• Forbidding one-on-one meetings
• Don't share information
• Implying that everyone can be replaced
• Micromanaging

All of these behaviors increase ambient fear and can cause a cloud of anxiety to loom over the organization.

Losing Your Job Fear

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. This also can cause management to believe that heroic effort is a common and acceptable part of the software development. An occasional "work push" is one thing, but if EVERY RELEASE cycle means a heroic effort at the cost of your personal relationships, you've got problems.

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. Fear of bug regressions - a closed/fixed bug coming back to life also stresses developers out.

Can you think of other flavors of Fear Driven Development?

* Photo by Stacy Brunner, used under Creative Commons

Sponsor: Many thanks to Aspose for sponsoring the blog feed this week! Aspose.Total for .NET has all the APIs you need to create, manipulate and convert Microsoft Office documents and a host of other file formats in your applications. Curious? Start a free trial today.