Increasing technology seems to produce increasing levels of fear.  Take food.  If it’s grown on a farm without chemicals or fertilizer and carried by the farmer to your house in a horse drawn cart and you cook it yourself (or better yet eat it raw) then you feel safe (unless you cook like me).  Add just a little technology (like putting it in a truck and processing it in a plant) and people get a little more suspicious.  Genetically engineer it, irradiate it, kill the bugs with chemicals and add things with long names like ascorbic acid (vitamin C) and many people will refuse to eat it.

If something as simple as food can create fear, just imagine the fear that something like Code can create.  The word itself conjures up images of secret societies and strange rituals.  We imagine a massive iron door with a tiny window that slides back so a shadowy pair of eyes can ask, “do you have the code?”  You pass a note through with the words, “ACM EJB purification ritual at 0500″  It’s not too surprising that even amongst the chief purveyors of code (programmers) code can be a source of fear.

In life, fear can be a powerful indicator that something is amiss.  If my kids come home from school and they say they are afraid of Ms. Wormwood it’s worth taking the time to find out why.  Probably it’s just because her sweater smells like it came out of a trunk where it had been sitting for forty years and because she spits when she talks, but just perhaps there is more to it.  Sometimes the thing that is amiss is outside of us (like a burning house) and sometimes it is inside of us (like my irrational fear of Gummi Bears).

Just as in other areas of life, the fear of code can be useful for figuring out what to do and what not to do.  The secret is to understand where that fear is coming from.  Below is a list of a few kinds of fear of code that I have encountered over the years and what they might mean.

Fear of black holes

A black hole is a piece of code which is slowly sucking in an entire company.  Engineers assigned to it are either permanently assigned to it unable to escape it’s gravitational pull, or else they are sucked from the company entirely (appearing in an alternate company).  Fear of a black hole is fully rational, and some veteran engineers have highly attuned senses that can detect the presence of a black hole (sometimes even before it is fully formed).  They will often refuse to work on that code.  Working on black hole code is what caused Eric’s head to explode.

There are basically three reasonable responses to black hole code, and not all are available in all cases:

1. Keep people away.  Just keep clear of the thing.  Don’t touch it; don’t change it; just leave it be.  One way to do this is to wrap the black hole in to an object or set of objects from which you will expect reasonable behavior and allow those objects to manage every interaction.  This is often impossible, and if the gravity of the black hole is too high these external structures will be further sucked in making things worse.
2. Blow it up.  Now with real black holes this is not an option, but with black hole code, it just might be.  The only tool powerful enough to blow up a black hole is aggressive refactoring.  In a sense, if refactoring is possible you don’t really have a black hole, instead you have some very large stellar body, perhaps a brown dwarf.  The danger of refactoring a black hole is that you will get sucked in OR it will explode.  By explode I mean that it is fragile enough that your tinkering will created massive bugs or it will bring the code to the point of utterly not working leaving your company dead.  The trick here is determining how powerful your refactoring skills are and how unstable the code is.  If your skills are weak or the code is too unstable this is a dangerous course to set.
3. Move to another part of the galaxy.  This is the final solution.  Write new code to replace (completely) the old code.  If your company is small the effort of doing this may not be manageable and you will die.  In other words, it was probably too late and the best option was to keep people away as best you can and hope for some good fortune to come your way.  Even in a larger company, it may be that the black hole stems not from the code but from the problem itself (or the talent of the engineers).  Rewriting will not solve these problems; you’ll just have a shiny new black hole to replace the old one.

A good way to remember these three options is that you can “retreat, refactor or rewrite.” 

Those of you who do not believe in black holes, just remember this: estimates suggest there are between 100 and 200 billion lines of COBOL code still in use today (that’s billion with a ‘B’) and between 250,000 and 1.5 million people writing it (Google).  Since very few new projects are started in COBOL the presence of black holes in the universe appears likely.

Fear of the dark

Fear of the dark in programming means being afraid to go where the path is less clear.  Managers are highly susceptible to this fear.  It is a rational fear.  When we do things we are unfamiliar with we make mistakes out of ignorance.  We trip over things we don’t see.  The problem is it’s only a rational fear in moderation.

If we have too much fear of the dark we will always use the tools that became popular two years ago.  We will over-design to make sure we’ve gotten everything perfect before we begin.  We will never let junior developers write code.  We will never write any innovative or cutting edge products.  In short we will be indistinguishable from everyone else.

The secret to fear of the dark is oneness with it.  Feel the fear and confront it rationally.  Does the short but dimly lit path through Eiffel appear to be a better way to your destination?  Look about, experiment and try a bit.  Take a few steps remembering that you can still turn back.  If a light switch is available, turn it on.  Use your fear as a guide but do not let it control you.

Fear of crime

The fear of crime is the fear that someone will hack your code.  It exists on the boundary between the rational and the irrational.  The irrational fear of crime is the kind that takes place when programmers write code that is excessively defensive. 

If you have made the interfacing class final and made all of the related classes private static inner classes and bound in a proxy layer so that other programmers “can’t” possibly use your code in a way other than the way intended you are verging on the psychotic. 

If you have encrypted the password used by your application to access the database, placed the database in an isolated subnet, made it so the application can only be booted when a user is present with a special two-factor authentication device and used 5000 bit encryption throughout, and your application is an intranet portal that gives out home phone numbers you are delusional and psychotic.

Crime exists.  The secret is to turn down your fear and turn up your science.  Ask who will want to break in, how valuable the system is, and how much energy will it make sense to spend to keep people out.  If you write intrusion detection systems or keep millions of credit card numbers it’s not called fear it’s called sanity.  If you write in house applications and the only attackers are malicious internal people, ask yourself how good the rest of the security is before you try to make your system a Fort Knox specially designed to keep people from sending malicious emails. Be prepared to recover from crime rather than trying to preventing it. 

Fear of getting wet

This is an irrational fear.  It is the fear of diving in and trying to do things.  It is the fear to experiment and the fear to be wrong.  This fear is irrational because it can’t ever help you.  If you are afraid to try out your fix to the bug what will you do?  Hope it fixes itself? It’s not that you won’t be wrong, you will.  It’s not that being wrong won’t occasionally create problems, it will.  It’s just that these problems can’t be avoided no matter what route you take.  If you use your mind and write the best code you can then that was your best!  Be proud.  Learn from your failures and keep coding.  If computer science is a science at all it is an experimental one, so experiment.  Be fearless.

What are you afraid of?

These are really just a sampling of the flavors that fear takes in engineering organizations.  My hope is that you can take a look at yourself and your team and see what you’re scared of (maybe it’s requirements creep).  Then, instead of being afraid or ignoring your fear, use your fear as a guide for change.  Don’t be afraid of your answers.  Maybe you’ll discover that you would make a better scientist than an engineer or that you should quit and find another company to work with to escape a black hole.  You know your fears and you know your options.  So here’s my question again, “What are you afraid of?”