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.
January 26, 2009 at 5:15 am
This reminds me why I don’t really like LH…
January 26, 2009 at 12:38 pm
I get what you’re saying, but I disagree. I don’t think using fear as a motivation is healthy or productive in the long run. Fear pushes you towards a quick fix (such as abandoning a high-value feature because of too many bugs) or flat out denial (not looking at your bug tracker). These decisions come out of a lack of awareness and clarity. It’s not a healthy state to be in day-to-day.
These systems–bug trackers, for instance–do alleviate fear, but that’s a side-effect. They eliminate the symptom of fear by attacking the root cause, which is a lack of awareness. This is the promise of David Allen’s GTD, which isn’t really about a *system* or *lists* as it’s usually described but just one simple idea: when you try to keep everything in your head, it’s hard to see it all at once, and when you can’t see everything you’ve promised yourself you’d do at once, you don’t have the awareness to make an informed decision about what you’re going to do at any time.
Bug management systems *should* make it easy to catalog and hold onto thousands of bugs, if that’s the amount of good feedback the product has. That allows the developers the peace of mind that any known bug will be remembered and considered. But more importantly, a bug management system needs to make it dead simple to decide with awareness and clarity what the team should do next.
Here at drop.io, we’ve got a Lighthouse full of hundreds of tickets. Many of them haven’t been viewed since they were filed. Filing tickets is something we get. We haven’t figured out the second part: how we decide at any moment what to work on. Lighthouse tries to manage that with Milestones, but they just haven’t worked out for us. I think Pivotal Tracker answers that question much better, but at the moment, we’re in no position to switch.
We’ve made the conscious decision to live with the fear for now. Every couple of weeks we scan our outstanding tickets and try to pick out some important next steps. But it’s not ideal.
The fear doesn’t really help to motivate. It paralyses.
January 26, 2009 at 2:36 pm
> 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.
[http://www.thedailybeast.com/blogs-and-stories/2009-01-05/lance-for-senate/full/](http://www.thedailybeast.com/blogs-and-stories/2009-01-05/lance-for-senate/full/)
January 26, 2009 at 3:37 pm
@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
January 26, 2009 at 6:05 pm