This site is dedicated to the elimination of this error message and all that it represents:

The problem isn't just that the user doesn't know what error -5000 is. It's that the program gives the user no help with diagnosis. What was the program trying to do - both specifically and generally - when the error happened? What did it (or the programmer) imagine the user was trying to accomplish? How did it get to the point where things went wrong?

Today, we software people think only of two modes of diagnosis, if indeed we think at all about what anyone will do after an error happens.

The first mode is used by the user who knows nothing at all about the internal workings of the program. She has no recourse other than mostly-random changes in how she uses it. "It worked before, but then I tried doing this slightly different thing. I guess I won't do that thing." Or she flails around changing the program's environment in ways that might have some effect on it.

The second mode is used by the programmer who wrote the program. She opens the source code, fires up the debugger, and steps through the program. She can see as much of the workings of the program as it's possible to see.

This web site is about the middle ground: adequate visibility into the internal workings of programs - a visibility that serves the needs of users, programmers, and testers.

Here are some of the themes that organize my work. They extend beyond supporting better error handling.

To serve users, I want to promote the notion of "tinkerable software". Tinkerable software allows the dedicated amateur to tailor it to her needs, even though those needs were unanticipated by the software's builder. (Thus, a Preferences dialog doesn't cut it.) Emacs is the canonical example of tinkerable software.

Hand-in-hand with tinkerable software goes "explanatory software". Software should be able to answer the questions I so often ask my children: "What were you doing when the vase broke? No. No. Before that. Uh huh. Why did you take the vase on the roof? What were you trying to accomplish?" As with children, the conversation will not always be satisfactory and the answers won't always make sense, but - as with children - the software (or, rather, its programmers) should at least try. For that to happen, there will have to be tool support and also social support. 

Explanatory software goes hand in hand with tinkerable software because the dedicated amateur will need explanations to do the tinkering well.

Software that serves users will also serve testers who practice "grey box" testing. Such testing depends on a certain amount of visibility into the structure and workings of the code. It also requires control over those workings. For example, testers may need to inject network errors in order to test the program's error handling. This visibility and control goes by the handle "testability", but it is unfortunately usually quite ad-hoc, poorly implemented, and low-priority. Again, there are both tool support and social issues.

Finally, there's programmers. They are often dropped onto a project and told to fix bugs or add features. They don't have time to take advantage of the theoretically maximum visibility that they have. They need to understand quickly just enough about the whole system, otherwise things they change here can cause something to break over there. It's sad when working on a system feels like working on a house of cards: the slightest change, and it will all come tumbling down.

To that end, I have two directions of work. The first explores ways programmers can write code that helps their successors. The second assumes that their predecessors didn't do that, so they need tools and techniques to help them cope.

Notice especially that all these people - users, testers, and programmers - have something in common beyond the need for understanding: they don't have much time to get it. They have other things to do with their lives.

So I will concentrate on how one can do as little as possible to achieve adequate understanding. Adequate understanding will not be complete, will not be detailed, and it may not even be correct. It just needs to be good enough for the task at hand.

Visit the site map for a listing of what I've accomplished so far.

One final note. You'll find a lot here about the Ruby programming language. What does that have to do with adequate understanding of system internals?

Well, I could say that a pleasant, expressive, flexible language like Ruby will help with this, just as it helps with every development task. I do in fact believe that. But the real reason is that I like Ruby and, of my web sites, this is the most obvious place to indulge my liking.