Good stuff in many blogs all around

I was recently looking around at some good old blog posts and some of their comments by other people.

Chris Becker in his post here links to this old post by Chris Pratley, which has a comment by Rick Schaut which begins:

   I've often referred to bugs whose ease of reproduction appears to run inversely proportional to the rigor with which one attempts to observe the cause of the bug as "Heisenberg" bugs.

I've heard them called "Heisenbugs". Heisenbugs are the reason why whenever I debug anything UI related I do it on a second console. It is the reason that unlike many other developers at Microsoft, each of my computers has its own keyboard, video, and mouse (and why I don't use KVM switches any more). My typical example of a Heisenbug goes something like this:

   "Do {some complicated operation} in the UI and {something} doesn't redraw/update properly."

This is one class of UI interaction bug that is very difficult to debug on the same console as the debugger. The reason these bugs are Heisenbugs always goes something like: you switch windows to the debugger to investigate some piece of the problem and the window switching process causes an invalidation or other messages to be pumped to the application which fixes or changes the problem. Visual Studio has the wonderful ability to Remote Debug a second machine, and that's what I use to debug just about all the time. It lets me see on one computer what the application running on the other computer is doing at a frozen moment in time. But enough on Heisenbugs (for now), I just thought I'd throw out one way of looking at the problem.

So anyway, back to my train of web links, I was looking at Rick Schaut's blog post here, and then I read this post from David Weiss which reminds me that nobody's perfect. So here I am reading Chris Pratley's latest post about why there is no OneNote viewer, which references a rather old post of his that he answers in an interesting way a few weeks later with another post about design.

So I went from reading posts about why we put the brakes on taking fixes late, to posts about features which get cut, to the design of a product. Development has a lot to do with a principle I learned in a freshman economics class called opportunity cost. Our time on this planet is limited, and what we do with that time we can only do once. There is an opportunity cost of spending that time working on one of many different challenges/problems. That cost is that you can't spend time working on anything else. If the people at Microsoft do our jobs best, we spend that time working on the most important challenges/problems first.

In simpler words: we ship with bugs (any feature you don't like is a bug). If we did our jobs right, then we have addressed the most important bugs and the only bugs left over that we ship with are the ones that you care least about. That is the theme of the blog blog posts I have been reading. I wanted to end by saying that there are lots of passionate people at Microsoft.

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

• Anonymous
  December 28, 2006
  In a post about opportunity cost, I wrote: "Better yet, rather than explaining to these guys why I might be inclined to fix someone else's problems before I get around to fixing theirs, I can spend that time actually fixing bugs." I don't know how many people got it.