I just read Robert Patrick’s essay on eMuseums, hosted at Paul McJones’ excellent Dusty Decks blog. It’s a great read and addresses some of the problems of presenting computer history in an effective, and extensible, fashion.
I was specifically interested in Mr. Patrick’s thoughts on presenting software history. Hardware is a more intuitive museum subject in significant ways (its object-ness among them), but of course museums successfully convey subjects which have no direct corresponding object (e.g. touching the actual clothes of a Civil Rights victim) quite well. Still software remains especially difficult to present in an interesting way.
Mr. Patrick states that software’s workings are opaque to users, and suggests a multithreaded approach to software history that documents the different software types (applications, subroutines, operating systems, etc.) as they emerge, ascend or recede over time as separate threads.
Along with this, I am specifically interested in conveying to the museum goer the architecture, engineering, and writing of software. There is no better way to communicate the human labor, ingenuity, and yes, the toil, that goes into software making. Quoting industry numbers does not tell the museum goer that software is frequently an epic engineering project with considerable drama, not just externally (between departments, coders, and investors), but internally as well (in engineering problem solving). How to convey this drama?
Software is both an engineering and creative endeavor, and it exercises a rich figurative language that suggests physical play and work: variables are passed, object are created, something is trimmed, cleaned or scrubbed, a request is made, an exception is thrown, a thread stops and starts, etc.
I think this language indicates a way to illustrate the software engineering problem space abstracted away from specific commands and syntaxes. For example, museum visitors could manipulate some system (either a physical system or video game-type piece) with certain constraints emulating those of the coder. Come to think of it, puzzle games do a fine job of such demonstration already (perhaps more Portal than Braid). They could likely be much better demonstrations, of course, if they were directed toward this specific purpose.
I would love to see the day when some of the problems, solutions, tricks, etc. of software engineering are conveyed as well as those of medieval cathedrals or the Giza pyramids.
Walker Sampson 