Operant Conditioning by Software Bugs (2012) | Hacker News Reader

Operant Conditioning by Software Bugs (2012)

blog.regehr.org

48 pointspanic20 comments

Many years ago, in my first tech support job, I was helping a bright young student submit an online assignment. It was clear very early in the conversation that she was bright, so I –very unconsciously– made some assumptions. After much frustration at my inability to diagnose why she wasn't able to submit her assignment, I broke down and told her to tell me exactly what she was doing, step-by-step. It turned out she was successfully navigating to the webpage and filling out all but one of the text fields by tabbing to the field and typing in her response. But when it came to pasting her essay into the webform (from the word processor), she assumed that by selecting the browser's edit-paste menu, it would put the essay in the essay field.

It genuinely would have never occurred to me that a browser's edit-paste functionality would _know_ which textfield to paste text into. Likewise, it genuinely never occurred to her that a copied essay would be pasted into anything other than the only text field large enough for an essay, and the only text field which was labeled "essay".

Some keen observations here. I think many of these idiosyncrasies in computer systems that encourage ritualistic user behavior also contribute to subconscious expectations of how systems should behave, and lead to an implicit inference of architecture from observed behavior that may or may not be proper. In turn, programmers propagate these expectations into their own work and continue the cycle. It's not about knowing what you want, it's about wanting what you know.

Speaking of frequent rebooting, I always thought the lack of support for orthogonal persistent state, seamless application checkpointing and built-in dynamic software upgrade facilities represented a failure in modern mainstream computing.

When a system is in a complex, poorly-tested state, problems often occur. Rebooting solves these problems by putting the system back to a simpler, more predictable state. With orthogonal persistent state, the system remains in the complex state across reboots, and these problems become much more difficult to solve.

As a user, I agree that persistence is really nice, but I think we need to address the existence of these complex, poorly-tested states before we start transparently persisting them.

The only reason the Web works with such crappy coding is that the browser/server relationship is almost stateless. As new web technologies maintain more persistent connections, expect advice along the lines of "close the tab for the site and reopen it". Except sometimes you'll have to exit the browser completely (can you do that with IE?) to clear the connection.

And this is why perhaps the old microcomputers were perhaps more user friendly than the modern PC.

This because they were for the most part single task, and usually had a full reboot done before a new task was initiated.

Your last point is a big reason why mobile/tablet systems have become so popular, and why that technology set will filter back towards desktop computing. Managed apps (package managed installs, one click install/update/uninstall) plus seamless app hibernation and resumption are overall a big win for usability.

The former has exited in one form or another for ages.

As for the other, personal experience indicates that it is of questionable value at best.

I have seen way too many apps either not come back up, or come back up in some insane state. As such i consider it no better than the autosave on a wordprocessor.

I don't see how mobile systems come close to what I've described. I never mentioned package management, either.

I suspect that if NVRAM fulfills the promise of DRAM-speed and DRAM-price with persistence, that will become the natural model, which will require a bit of a revolution.

My first thought is that it will make cold-boot attacks and cryogenically-frozen-RAM attacks much more viable in practice.

"Oh, you have to do a full reset. Shut down the computer, wait ten seconds, start it again, hold ctrl+alt+F4, wait for the double-beep, then let go of the keys. Yes, do this every time it locks up."

Maybe we'll end up with something the equivalent of fsck but for the in-memory state.

     it's about wanting what you know.

And this in part is what has kept MS on the desktop, as they used to bend over backwards to make sure old binaries ran on new OS releases.

Supposedly the DOS version of SimCity had a bug/oversight where it accessed a ram segments after freeing it. This because while DOS was supposed to enforce access restrictions, it has failed to do so in early versions.

But rather than let said game crash on newer versions, MS put in a conditional that disabled the enforcement if it was the SimCity binary that was running.

You also find this in the "do not break userspace" that Torvalds enforce within Linux kernel development. Once code is in the kernel, its APIs are to behave the same for perpetuity. Thus it can be damn hard to get new code in the door if it adds a bunch of new APIs.

Sadly userspace devs are less conservative about API breakage...

A good piece, though the Microsoft hate is slightly unwarranted. I have been keeping my windows machines running 24/7 since the NT 4 era, and they've universally had uptime of many many months most of the time. Though there's much else that I would criticize Microsoft software for, uptime of the OS isn't in that list.

NT is infinitely better in this regard than the old DOS based Windows.

I seem to recall a claim that it is easier to adapt the human to the interface than the interface to the human.

And for some reason i have it mentally attributed to Apple...

> Programmers are notoriously poor at finding their own bugs—especially subtle bugs—partially because of this immunity.

That's why I like QuickCheck so much. It'll try all the corner cases, I wouldn't reliably think of.

I wonder what bugs I have trained myself to be unaware of in my Linux/Firefox/Emacs/Haskell setup.

One big problem is getting people to read error messages. It's hard work trying to write a relevant, helpful and localized message for every conceivable thing that might go wrong, only to have the conditioned users immediately click the X and call and complain that it's "doesn't work"

`User blindness' is a problem, but good design can also help.

Eg instead of confirmation dialogs make as much undoable as possible. GMail goes so far into that territory (originally by accident) as to introduce a delay before sending your message to give you time to undo.

Reply on news.ycombinator.com