Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Fear and loathing in software development

There’s a reason you don’t stick your hand into fires, walk into traffic, or use Windows Vista. Humans, along with pretty much every other organism with a central nervous system, have evolved fear as a defense mechanism that protects us from doing things that cause us pain. We can override this to a certain extent, but fear is instinctual and basic.

Now, a lot of the ideas and practices that fall under the umbrella of “Agile,” exist largely to remove fear and pain from the software development process. Detailed and extensive tests remove the fear of breaking things when we make changes; pair programming and collaborative work remove the fear of getting stuck on a problem, or learning a new domain or technology, or having someone leave the team. Rapid iterations and rich feedback remove the customer’s fear of not knowing the true progress of the project, or having not having the really important stuff done when the deadline comes.

On top of this, we build more tools every day to make our lives easier and less painful. Rails itself is a great example: it removes the painful and tedious bits of creating a website, removing the fear a web developer might have of becoming mired in details and configuration. But, are all of these tools that reduce fear good things? After all, we’re much more likely to jump headlong into something we don’t fear.

Bug management systems are an example of this. They exist for one reason: to make dealing with a lot of bugs less painful. If a system has three bugs then there’s no real reason to prioritize or filter them. If that system has three thousand bugs, then the situation is quite different. Just looking through the bugs without some form of sorting or filtering would be quite painful. But, isn’t an out of control bug count something we should be afraid of? Do bug management systems make it too easy to manage a situation that we should be doing anything to avoid?

Exception notification systems for Rails are another excellent example. Personally, I like ExceptionNotifier. It sends an annoying email to, ideally, your entire team. That’s it, no frills. Now there are systems like HopToad and GetExceptional that manage these exception in a friendly way. Again, do these tools remove the wrong kind of pain? Shouldn’t we be afraid of runaway exceptions?

Personally, I like the idea of leveraging basic animal instincts to keep us on the straight and narrow. Programmers will tell you that they know the right thing to do, that these tools don’t create any disincentive to do the right thing. But, I suspect that someone with an anesthetized hand would be a lot less careful about sticking it into a fire.

  • I’m a getexceptional customer, and one of the things I like is that your exceptions are then archived, along with any comments that might have helped you track down the solution. So if a tricky exception pops up again in another project months down the line, you don’t have to go digging through your inbox to find it. For me it’s about separation of concerns.

  • This reminds me why I don’t really like LH…

  • Steve C

    > The fear doesn’t really help to motivate. It paralyses.

    One more datapoint:

    Daily Beast: What drives your competitive nature?

    Lance Armstrong: Fear of failure.


  • Chad Woolley

    @Lar Van Der Jagt,

    I do the same thing manually for exception notifier emails. I paste the subject into a tracker ticket, and the relevant parts of the body (usually down to first app code line of stack trace) into the description.

    This means they are tracked, archived, and searchable.

    Yes, this is a bit manual and painful, but that supports Adam’s point that they should be exceptional and painful.

    — Chad

Share This