Getting bugs out of our systems

Very soon after we start learning to program, we start learning to deal with bugs.   Folks who have programmed for a while might forget that effective bug handling, like effective programming, is a skill that doesn’t come entirely naturally.

Many of us instinctively avoid criticism, ignore it, minimize it, or even argue against our critics.  But our programs will almost invariably include bugs, and to handle them, we have to go against the grain of our instincts.  If we’re smart, we make it as easy as possible to report bugs to us, so we minimize their impact.  We respect and listen carefully to what our clients tell us, to understand the problems they’re encountering with our product.  After we fix the bugs, we often  review our code and our practices to avoid similar problems in the future.

It helps a lot if we can keep our egos out of the bug-fixing process.  I know that my work will sometimes have bugs, and that a bug report should not be taken as a personal attack.  Rather, I try to make it an opportunity to improve my products and my future work.

Bugs exist at various levels.  Bugs that cause crashes are often the easiest to deal with: it’s clear that something is going wrong, and it usually isn’t hard to figure out what to do about it.  But less obvious bugs can be worse.  One product our library uses, for example, implemented boolean searches incorrectly, omitting important results. This kind of bug can mislead lots of people who never notice the problem.   (And it can also take longer to address.  I had to send multiple emails and examples to the developers of this product before they admitted that their implementation was buggy.)

Bugs at the overall system level can be the worst.  The reservation system with interminable holds, the customer support service that never returns our calls, the open source effort that repels key constituencies it should be attracting: all of these are buggy systems, and they can drive people away just as surely as a crashing program.  As Michael Bolton puts it, “a bug is something that bugs somebody who matters.”  System-level bugs can be challenging to fix, but they can be the most essential to repair.

I hope none of these principles seems new or controversial.  But I’ve recently seen a few bug reports concerning the Ruby on Rails community that drew many responses that ignored them.  The reports concerned buggy systems, not buggy code.  In particular, they noted a professional developer conference that attracted very few women, and an accepted presentation at that conference that included blatantly unprofessional themes, themes that one could easily predict would put off many of the people who could benefit from the talk.  (They would be particularly problematic if you were one of the few women there, but I found it distinctly off-putting as well.)

The comments on those two posts include plenty of examples of denial, minimization, rationalization, and attacking the reporters of the bugs.  (Indeed, some read as if they were cribbed right from this checklist of cliched defenses of in-group privilege.)

Assuming that the respondents are active members of the Ruby community, the responses suggest that there are still serious social bugs in that community.  I recently came back from another open source-focused conference (one that had a significantly higher proportion of women, though still far from 50%), where there were some good things said about using Ruby on Rails for library application development.  I like open source projects with good technical bases, but if I’m going to rely on a technology, I want its developer community to be healthy.  Healthy communities generally provide more reliable, long lasting development support, and can be much easier and more pleasant to work with.

It can be positively uncomfortable for many of us to confront social problems, particularly ones in our own communities that we might be partly responsible for.  (And Ruby is not the only community that’s had this kind of problem.)  Perhaps if we get used to thinking of these problems as bugs, welcoming and paying close attention to reports, and getting our egos out of the way, we’ll find it easier to fix them.

Gender inequities are bugs in our systems.  Bugs happen.  But they can be fixed.  As my library considers involvement in various community source development projects, I want to find out more about what these communities are doing, going forward, to fix and prevent these sorts of bugs.

Author: John Mark Ockerbloom

I'm a digital library architect and planner at the University of Pennsylvania.

3 thoughts on “Getting bugs out of our systems”

  1. We do have a lot of bugs in our systems. The issues with the Rails community are not unique to that group and are generally reflective of larger issues in our society. I also have to say that the Rails community has responded really well to my initial “bug report” (if you ignore the noise from a few unenlightened individuals). I think it is important to distinguish talk from action… although talk can be damaging, it is noteworthy what actions are being taken.

    A new group “RailsBridge” has formed of people who want to create an inclusive and friendly Ruby on Rails community. There are a number of people who have stepped up to lead specific projects that we feel will make a difference. I signed up to lead a group teaching programming to kids — it doesn’t have anything directly to do with Rails, except that this community was willing to help and believes that we need to think about both long term and short term solutions. There is tremendous energy coming from this group to catalyze positive change. I am honored to be a part of it.


  2. RailsBridge sounds very promising; I’ll definitely recommend we get involved with this if we do start working with Ruby on Rails.

    Thank you both for all you’ve done (both with talk and action) to foster more inclusiveness in information technology. I agree, and hope I made clear, that the bugs in the systems aren’t limited to any one particular group. I hope to make some contribution to debugging in my own environments as well, and hope that lots of other people will do the same.

Comments are closed.