This is Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Established 1999 in Chicago. Visit the Product Blog for more information on our products.

It seems obvious, but it’s nice to put it into words, isn’t it?

I’d like to know what prompted this post, too :)

Well said. Programming does tend to lead one to think in rather irrational ways, oddly enough. But if we were purely logical beings, we’d be robots and the world would be a lot more dull :)

Thats a good way of putting it. I wonder how clients would respond to it. “Sir…its not a bug, just unintended causation”. Then charge a consulting fee of $250 dollars for using big words. Bam.

Not so much relating to bugs, but in terms of your comment regarding breaking down large problems into smaller pieces – I’ve been thinking a lot lately about how this concept relates to the “flow” state as coined by the author Mihaly Csikszentmihalyi. I think this is what makes practices like test-driven-development and GTD enjoyable and productive for so many. One of the main things you need for achieving the flow state is small, achievable goals. I think if you are constantly focusing on breaking everything you do down into smaller pieces (programming problems in particular), you can really get in the zone and enjoy what you’re doing even more.

Sorry for the extreme tangent, but I’d be interested in hearing thoughts or strategies for this flow-based development mindset.

I can totally relate to that post David. I can’t count the number of times I’ve hit an “unintended causation” I just can’t bust and I start to get irrational in my irritation at the problem. I’ve learned that I simply have to force myself to work on something else for awhile or take a break. Once you let your emotions play into your programming, especially frustration, you turn the logical part of your brain off and you’re much less likely to find the source of your problem.

TDD certainly does seem mitigate the occurance of these situations, but it sure doesn’t eliminate them. There’s still plenty of times where you’re clueless as to why you can’t get your test to pass.

Try to put a positive spin on “unintended causations.” Looking back on my experiences as a programmer, bugs have been the catalyst for me learning more about the language and frameworks I’m using. Thanks to bugs, I know a lot more about the internal workings of Rails and that knowledge has made me a better and more knowledgeable programmer.

So… don’t think of a bug as a roadblock, think of it as an educational opportunity. :)

Haha, love that you used the word Hobgoblins in the text=D

Also, as always, good written and interesting read=)

technically, the system does exactly what the code describes, so code itself can never be buggy. Great point re: lack of information being the source of bugs. Very much also the case in human interactions.

Greetings, I get unreasonably upset when a bug ‘vanishes’ without any developer consciously doing something that would resolve it, and everybody gets happy that it’s gone. It needs to be understood why it happens, or it’s possible the bug has gone into hiding. There’s a palpable sense of relief when the actual underlying cause of a supernatural-level issue is finally resolved.

That said, the very term ‘bug’ implies something that creeps into your code on its own. I like the term, ‘Massive Foul Up’ (you can replace the F with…oh…whatever you’d like. :) It comes from ’ No Bugs!: Delivering Error-Free Code in C and C++’, specifically:

Software bugs do not sneak into code on their own. Some programmer put them there. Rather than treating bugs as inevitable, treat them as a Massive Foul Up (MFU).
— David Thielen

— Morgan

I’d just like to point out that, in the most enlightened of software development shops, nobody blames developers for bugs. They are not a “massive foul up,” nor are they really anyone’s fault. Bugs happen. They are a natural consequence of turning ambiguous rules into explicit instructions.

One of the best parts about Test-Driven Development is the idea that “bugs are unit tests you haven’t written yet.” That implies, A: That bugs stem from ambiguous requirements – had you known to write a test for that situation, it wouldn’t be a problem; B: That bugs just mean that you’re not completely done yet; C: That you’ll always check for that kind of bug again, and hopefully remember that kind of unit test in the future.

-Ben

Unless you’re dealing with non-deterministic concurrency bugs. Then it’s just turtles all the way down.

It one of the unique talents of the Evil One that he puts bugs into our systems when we are not looking. Yet simultaneously everything that is in there was put by us. He directs our hands and minds off the path of truth and logic and into the shortcuts of fuzzy thinking. He has has His own miracles and distracts us with meetings and network slowdowns.

As Maimonides said, development of the intellect is virtue.

So, it really was the Devil, all along!

‘Bugs’ for me are an integral part of developing something new and exciting. I actually relish bugs, they give me the opportunity to see exactly whats going, learn why it isnt working and more often than not, give me a better way of doing something (usually by simplifying the code). I’ve rarely coded something and it’s worked first time and worked exactly how I wanted it to. Developing and bugs come hand-in-hand for me, they shouldn’t be used as a negative point in development but embraced and used to develop your skills and give you better understanding of how and what information is being moved around.

The joy of finding that bug after interrogating your code for what seems like hours, then realising what an idiot you were for doing it that way, fixing it with a couple of keystrokes, sitting back and going “yeh! Got ya!”

Well, sometimes there are bugs too. Not due to lack of information or anything other than the fact the programmers are human beings, and human beings make dumb mistakes. Not mistakenly thinking that A results in Y, but more not knowing what you were thinking at all. I mean, what was I thinking?

Happens daily. Embrace the opportunity to fix things.

You didn’t think that A would result in Y, but was convinced it was Z.

The bug is not a “massive foul up.” That the interface of the app used has not been redesigned specifically to reduce certain errors probably is a MFU .

Going Beyond Syntax Highlighting would be a step in the right direction. And it would do more than the invocation of hobgoblins or “blame the user” diatribes - although it affords an amusing turnabout when the programmer is the user - it does not do much for the sense of control.

While it sounds dubious at first, the idea of “active debugging” as you code is intriguing as well. I’ve only seen a mention of this (somewhere) and never really checked out the latest developments.

This, to me, seems a more 37signals-like take on the subject.

There are no car accidents, only unintended intersections of 4 wheel vehicles.

I’ve always hated the term “bug” as it really does a disservice to the true nature of the problem. It implies that some outside independant agent is responsible for the problem.

The original bug was really a bug that crawled into a relay causing an early digital computer to fail. This was a variable outside the scope of what the system’s programmer should be responsible for. This isn’t a good way to describe a software defect.

What most people refer to as bugs are truly mistakes – shortcoming of us humans to take all possible variables into account and a lack of care (or time, or budget) to test or restrict the complete range of possible program input.

It sucks when we realize our imperfections but it does can at least drive us to improvement.