I've really been getting into IT Conversations recently, downloadable interviews with people in a wide range of fields, not just technology. For example, Ben Saunders talks about his solo unsupported trip to the North Pole, Ethan Zuckerman on technology in developing countries and Spencer Wells on his work in mapping the movements of man 60,000 years ago via DNA analysis. Check if out if you haven't already.
The one I'm listening to right now is with Kent Beck (of Extreme Programming fame) with some really great ideas on what he calls "software health". This particular bit had me on the floor in stitches:
My goal is not quality software, my goal is healthy software.
...
I remember hearing a description of the release process at Microsoft and someone likened it to Jello. You got this software and it's like Jello and people are making changes and it's shaking and it's shaking and you think you're getting close but the software's still shaking and then it stops shaking just for a second and that's when you ship it.
That's why I'm not interested in quality, I'm interested in health. Healthy software is not like Jello. It doesn't have that sense of "Oh boy, is today going to be the day in which there aren't any bugs in my software?"
Lord knows, I've worked at enough places that didn't even bother waiting for the Jello to stop shaking. And while I've never been a big fan of Extreme Programming, there's plenty of food for thought in this interview if you're at all interested in writing software that works.
OK, so I just wanted to be Google's first result for the phrase "Jello bugs" 
I am a 
Thanks for creating this, I cant go back to any other browser.
[...] And while it’s true that there is a huge divide between good and bad programmers, let alone the great and the truly terrible, a lot of it, IMO, can be explained by attitude. The best developers got that way because they gave a damn. It’s not enough for a piece of software to just work, it has to work well, and on many levels: the way the code was designed, the way the code was written, they way the user interacts with the software (or not ), how it was documented (yes, really! Good documentation is part of it!). And the best developers are always looking for better ways to do things, honing their existing skills and picking up new ones. The worst ones are happy just to shove something out the door, even if it’s built like jello. [...]