Aug. 1st, 2010

aleph3: (Default)
A few days ago I pitched in to help with inventory at the bookstore my wife works at; "inventory" in this sense meaning adding up the list prices of the items in the store. I'm putting together some thoughts on this as an information system. Before embarking on that, though, I want to throw out a pointer and a small example.

One of the more aha! things I've read was the chapter of Peter Checkland and Sue Holwell's Information, Systems, and Information Systems entitled "The Information System That Won The War", which was about how the RAF organized and distributed (and protected) radar data: and so despite having radar which was not, technically, as good as Nazi Germany's, made more effective use of it. The core take-away, though, being that the only computers involved were rooms full of people who were very good at sums.

The corollary take-away, and the one which I'm always finding examples of, is: a lot of information systems are still made from things rather than bits, and that if you are going to move them to a digital platform, you stand to gain a great many things (scalability, distributivity, speed) but there are also things that a physical system provides seemingly as a side-effect that are actually extremely important to how people use it. And these things get lost easily.

As a very simple for-instance: a deck of cards. Both in school, and in job interviews, I've been asked to implement a deck of cards in various programming languages. This isn't a very complicated task, unless you consider one of the main settings in which a deck of cards is actually used: playing a game of chance with money at stake, a setting in which the incentives for providing a deceptive deck of cards are, let's say, considerable. So in card-games played with real decks there are a number of social processes which leverage the physical properties of cards to promote transparency and trust.

For one, there's simply the thickness of the cards, a familiar quantity: a deck deviating from 52 by a noticeable amount will do so visibly.

For another, there's the uniformity of the back face: which increases confidence that someone working with a face-down deck isn't able to discern the identity of the cards. At any rate, actually flipping and sneaking a peek at one is a very visible act which it's hard though probably not impossible to do under the eye of several other players.

Of course, there is card-marking as an exploit, hence shuffling and dealing conventions have a strong tropism towards showing the backs of as many cards as possible, making it harder for a marked card to pass undetected.

And shuffling itself tends to be showy rather than trying for maximal efficiency: the goal being not just to mix the cards effectively but to demonstrate the mixing to observers.

By contrast, you can have a class in your programming language of choice doing everything a deck of cards does in a half hour, but it remains a black box. When you play a card game online, you essentially have to take the probity of Yahoo or MSN, say, as a given: and indeed not just their probity but the skill of their development and QA team, so that there's no bug which might, if the change to daylight savings time happens mid-game, result in their being two Jacks of Diamonds in a deck.

All the same issues, of course, but with much, much higher stakes, show up in voting technology. The principle remains the same, though: if someone has skin in the game, they also deserve ways to check that it's on the up-and-up, and not just "trust the experts, peasant".

Profile

aleph3: (Default)
aleph3

August 2010

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
29 3031    

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags