for building invisible machines
I spent some good time last week chasing down a bug in our J2EE app. It turned out that I was using the wrong session attribute name. Actually, I was using a correct name, because we store the same object in session twice, with different names (let’s just not talk about that), and in some situations, the attribute name I used hadn’t been populated yet. When I wrote my code, I thought I knew what the attribute name was (and I was sort of right), but I didn’t double-check.
I enjoy finding my mistakes. I don’t mean that as, “better than QA finding them for me,” although I guess that’s true, too. I think I like finding them because bugs often stem from incorrect beliefs, and fixing bugs is a chance to revise your beliefs. Software is a belief-intensive activity: you believe the web server is configured a certain way, you believe your cookie is being deleted at a certain point in the log-out process. We believe these things because we don’t want to verify them, and as long as things work as we expect them to, we’re happy.
The fun starts when our beliefs don’t match our experience. Suddenly you’re faced with hard evidence that what you believe is wrong. You can choose to ignore your experience (foolish and pointless), or take time to investigate, and replace your belief with knowledge. What’s nice about software is that you can usually do this just by looking at source code or configuration files. Imagine how much easier science would be if we could understand a phenomenon by simply looking at its source code.
Maybe we rely so much on belief in software because it’s not our job to understand everything, but to make things work a certain way. Understanding is great, but working software pays the bills. Of course we have to understand lots of things to do our job, but since that’s not our goal, we abstract away anything we can. I mean, isn’t abstraction one of the core ideas of computing and programming? Building up layers of abstraction is like asking the programmer to sustain belief in the lower layers.
This shows up in lots of situations: developers arguing about whose code is causing buggy behavior, developers arguing about exactly what a tool does under the hood, developers arguing about which redundant server they’re running on… You can argue about anything you believe in, but you can’t argue for long about facts. Argument indicates conflicting perspectives or opinions, which mostly boils down to belief.
I guess the lesson here is to remember this, and not to be too certain in your (software) beliefs. If you find yourself in an argument, try to understand the beliefs on each side, and at least acknowledge that you’re stating a belief. Remember Voltaire: “Doubt is not a pleasant condition, but certainty is absurd.”
PS: Terry Pratchett’s The Bromeliad Trilogy (Truckers, Diggers, and Wings) is a great story about when belief and experience collide.
Finally! You can see a full-blown example of the techniques I’ve been discussing here (the code’s for IE only).
Sorry this took awhile, I’ve been a little behind lately. The good news is the code took me all of an hour to sling together…the real time was spent organizing, cleaning, and documenting it so it’s easy to follow.
DOM hacking is of course most widely used as part of Ajax, to update the page with whatever data the asynchronous HTTP call brings back — but you can still do a lot without ever leaving the client. For example, check out the JavaScript Tabifier. I haven’t looked at the code too much, but it looks like it’s in a similar vein.
There’s also code to make HTML tables sortable from Kryogenix.com, which I’ve used before — very handy. I believe it uses some of the same techniques. Maybe I’ll look them both over, and do a compare/contrast with what I’ve written here.
