Over the years I’ve worked for a lot of companies and on a lot of different teams and one of the most common issues I saw was fear of the code that was written. I’d like to expose you to this issue in detail and propose how you can work better and make your end result much cleaner.

What is Fear Driven Development?

Code is complex, especially when you’re working on a big project. Understandably, when you’re a new developer, it’s very scary to join up on a project like this and if you’re being asked to add new features you might be hesitant to fix issues you come upon. Most developers leave the code as is, not daring to reformat, restructure, or fix even the most minute issues. They’ll just do the bare minimum. This is what I call fear driven development; the fear to improve upon or repair code out of fear of breaking other parts of the code. As I’ve seen in my experience, this is a vicious paradox. The more fearful a developer is of breaking the code by leaving it untouched, the more likely the code will break.

As a clean coder, I’ll note that fear driven develop also acts in direct contest to the idea of never accepting a broken window. If a developer leaves behind the issues they notice in their code, it could eventually break the code. Even if an issue doesn’t break the code, the code slowly turns into a patchwork of different ideas and perspectives, creating a code that is bound to decay.

How to avoid Fear Driven Development

The easiest way to avoid fear driven development is to have no fear. Your goal should be to make every line of code perfect, whether you wrote it or not. This doesn’t mean arbitrarily tearing apart all of your colleagues’ work, talk to them. Ask them why they wrote this method in this way, see if you can find a common solution. This conversation isn’t only socially appropriate, it will also help you form a ubiquitous language within your team. This way, no matter how many developers are working on the code, it will look like one guy wrote the whole thing.
I know it’s always difficult to sound like the guy who is complaining, but focusing on the cleanliness of your team’s code will strengthen its quality, solidify its design, and improve both your knowledge and your colleagues.

[mc4wp_form]