Fear Driven Development

If you're an agile practitioner, you'll have certainly heard of most, if not all, of the following:

• Test Driven Development
• Behaviour Driven Development
• Feature Driven Development,
• Accept Test Driven Development
• .. and there are probably a few more which I haven't mentioned...

But have you heard of Fear Driven Development?  What does this mean?

Let me be clear, I've worked in many organisations, from start-ups to Blue Chips to some heavy-weight dot coms.  FDD isn't something new and isn't attributed to any particular place I have worked at.  It's not some manifestation of new methodology.  FDD is the product of a programmer's insecurity fuelled by code complexity, constant pressure to deliver new features, company culture and a resignation that things will never change.  That's just how things are, and there's no point in going against the grain. 

An anectodal story of how FDD manifests

Assume you're the new guy in the team.  They're all pretty friendly, but incredibly busy.  "Wow, these guys are hard working!" you think to yourself.

In an effort to make a good impression during your probation period, you learn as much as you can about the systems you will be working on.  Any documentation you find is either incomplete, out of date, or even worse, just plain wrong.    You have a look at the code and find multiple layers of abstraction [which I'll cover in a future post].   So, it kind of looks well-written, if not a bit complicated to understand. You find some Unit Tests, but they're a bit hazy and incomplete.   Some don't even attempt tell you what the test is trying to prove or disprove.  Confusion ensues.

After a few days of familiarising yourself with the code base, you find there's code in there which you're not completely sure about what it is doing, or even why it's doing it.

As you're still in the honeymoon period in your new job, you say to yourself "I'm new, so it will take a while to figure out, so it's okay not to have the full understanding."

You're given your first real-world task.  

"That looks easy enough" you say to yourself.   Then when you actually delve into the code and step through what's going on around the feature you're implementing or enhancing, you find yourself in a jungle of code.   You find yourself wandering aimlessly in the code trying to figure out what the hell is going on.   You have no idea what's going on.   Okay, you can use a debugger to slowly get there, but with all this abstraction and all these little things that happen it gets even more confusing.

Then you realise you've eaten up half your time finding your feet when you should have been writing good, testable code.    Instead, panic ensues as you don't want to look like an idiot.   You've already asked every member of your team a couple of questions each (so not to use up all your credit with any particular individual.  And hey, it's an excuse to get to know your colleagues, right?) 

Going against all your best-practice principles, you're getting nervous that you're not going to meet the deadline.   So what do you do?  Well, there's no choice but diving in and writing a bit of code where you *think* you need to put the code.   Dammit.  That's broken things.   You aim again.  Fire!   Doh!  That's the wrong place.   Confusion turns to nervousness turns to panic.  You've only got a few hours left to complete this task.   

Your team leader asks "How's it going?".  You say you're still wrestling with the code base and it's a bit confusing.  You've got to own up otherwise you're in for it when they find out you've not written a single line of production-ready code.  You're off the hook - temporarily. 

The next day you get the same question posed to you.  You nervously reply "Err, yeah, I think I'm on to something, but I'm not quite sure"

Your team leader is beginning to look a bit impatient.  He's under pressure to deliver a bunch of features.   You find yourself working late, and surprisingly, all your colleagues are working late too.  You don't want to let the team down.  Neither do you want to go through the hassle of looking for another job.

And so the vicious cycle continues.  The more pressure to you are under to deliver, the more hacky your code becomes.  It's the only way to get things done and not look bad.   You hope that nobody will inspect your code in the fear that you'll get that tap on the shoulder for a quick chat.  You're also getting worried that nobody discovers that you didn't write comprehensive unit tests (if any for that matter!)

Every feature you subsequently deliver envelopes you in panic.   How long will it be before you're found out?

For the enlightened ones, it dawns on them that the reason why the team are so hard working is because they're all feeling exactly the same way as you.  Nobody wants to be found out and they all work their backsides off in silence hoping nobody finds out about their hacks.

So there you have it.   That's how fear drives a team to deliver code.   That code base you're working on will have dire consequences on your company's future agility.   

If you stick around long enough, you will eventually see the proverbial hit the fan.  

My advice to you is that if you see code that sucks and a bunch of scared developers, either be brave enough to encourage better practices within your team and push back to your dev lead that this code needs serious refactoring, or do your best to start looking for a job elsewhere. 

Otherwise you will find that someone will be tapping on your shoulder one day.