blog

Digital Flintstones

by | Sep 7, 2012 | Developer Blog | 2 comments

Architect Michael Graves wrote an op-ed in last Sunday’s New York Times that raised my hackles perhaps more than it should have. He starts from the premise that some in his profession have declared that the act of drawing is dead in architecture, replaced in its entirety by various pieces of design software.

“Architecture cannot divorce itself from drawing, no matter how impressive the technology gets. Drawings are not just end products: they are part of the thought process of architectural design. Drawings express the interaction of our minds, eyes and hands. This last statement is absolutely crucial to the difference between those who draw to conceptualize architecture and those who use the computer.”

A few things popped into my head as I read this piece, and they all bring me back to the position that we’re all still just digital Flintstones. It’s very tempting to look at how far we’ve come as software developers, but it’s important for everyone to remember that in the grand scheme of things, we’re still taking baby steps on our computers, and not all the steps we’re taking are necessarily in a forward direction.
In the long run, though, we need to remember Clarke’s law that any sufficiently advanced technology is indistinguishable from magic. Graves’ mistake is in assuming that since he can’t use software today in exactly the same way that he uses graphite or ink on dried tree pulp, that software is inadequate, when the real problem is that we are still inching toward that ‘sufficiently advanced’ state.
I remember reading a similarly-tinged rant from the novelist and essayist Nicholson Baker in his essay collection “The Size of Thoughts” decrying the removal of card catalogs from libraries. On the one hand, the points that he made in the essay had great validity. An example that I remember is how the design of the card catalog evolved over the years to provide great opportunities for serendipitous discoveries — thumbing through an area of topic cards was an easy way to stumble upon related and on-point books that you might not have realized you were looking for, and at the time he wrote his essay there were no corresponding capabilities in library software. Perhaps it’s improved in the current state
of the art, but my local library uses catalog software that’s on the verge of being unusable even for the things that it was designed to do well. The better argument here should be “this software needs to be better and should do so in ways that are completely infeasible with wooden drawers full of paper,” not “man, if this is the state of card catalog software in the early 21st century, we’re doomed.”
I think that our velocity in this area is going to improve once we grow out of the age of skeuomorphic interfaces that we’re currently suffering through; instead of freeing ourselves from the limitations of the physical world, we’re being asked as developers to slavishly recreate irrelevant (and sometimes problematic) details of appearance and behavior found in real-world systems.
Most of us have become used to this in the last few years from the design approaches that Apple has been using in recent versions of OS X and iOS (Really? A stitched leather address book on my iPad?) but it might even be worse in software used in the Pro Audio and Music Instrument industry, where the developers working on audio processing software strive to make exact digital reproductions of 45-year old hardware and the UI developers take the exact same pains to reproduce the front panel displays and controls, sometimes including renderings of scratches. Never mind that the rotary knobs that work smoothly when gripped in human fingers are awkward and confusing when controlled with a mouse or trackpad. Musicians should just be thankful that their digital recording software doesn’t include animated reels of 2-inch tape and the corresponding time spent wasted while the tape rewinds before starting a new take.
As I’ve written here before, before I wrote code for a living, I trained as a composer. When I sit down to compose, I’m still sitting at my desk/keyboard with a pencil and a stack of staff paper. Like Graves, it’s part of my thought process as a composer (although I do have an incredibly cool mechanical pencil from Japan, it’s still just a pencil). From that point, there’s notation software that I can use to generate pro-quality printed output, but there aren’t really any suitable composition tools that are useful at that stage in the process.
Contra Graves, I can’t wait for the day when I or someone else creates those tools, not to attempt to duplicate what I can already do, but to let me do things that I don’t yet have any way to do.

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more