What would it help to start seeing?

According to Google, it’s been four years since I last published comments on the visual system of the frog. I feel as if I mention this all the time, but it may be news to many readers here that an animal’s eye is not a mere camera: it’s an image pre-processor that’s selective (and even transformative) as to what it tells the cooperating visual processors of the brain.

The brains of frogs, consequently, need not devote their limited cycles to considering things that aren’t moving: a stationary object is presumed-in-wetware to be not-food, and evolutionary fitness has apparently been increased by dedicating the frog’s synaptic firings to moving targets. (This yields a story element for the book of Jurassic Park, with simplifications in the movie that annoyed the experts no end.)

I use this as an entry point for discussing the difficulty of noticing long-standing problems: things that we have learned, through years or decades of experience, to tolerate as inescapable realities. There are, it seems to me, many things in our digital world that we’ve had ample time to stop noticing (whether literally or just cognitively) – as in, we don’t think of them as problems to be solved, but rather as facts that have to be accepted and accommodated.

They seem, like friction, rust and gravity, to be things that we can mitigate but should not expect to eliminate.

Should we stop unseeing them? What if we can blow up long-standing problems by changing our point of view? What if we can take, as our point of departure, George Bernard Shaw’s memorable comment that “The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.” I’m sorry, he did say “man” – but today the invitation is clearly gender-neutral.

What might be our most progressive opportunities to be unreasonable?

Stop unseeing the costs of being too clever

In a not-that-very-old textbook entitled Foundations of Algorithms, an end-of-chapter problem asks the student to compare two methods of computation that differ in their tradeoff of more development effort, versus less machine time for large problems: one method’s workload grows with the square of problem size, the other grows with “n log(n)” proportions. “If programmers are paid 20 dollars per hour and CPU time costs 50 dollars per minute,” it asks, how long will it be (in terms of number of times an operation is performed) before less use of machine time offsets more hours of programming?

When I see a question like this, it feels like asking what we should use to polish the beads on an abacus, or lubricate the moving parts of a slide rule. Imagine how many decisions of this kind were made in the 1960s, when programmers made less than $10 an hour but processing time cost orders of magnitude more: decisions that are calcified in code that’s still running today, and still requiring human effort to understand and update.

Ancient, arduous optimizations of code for a particular machine architecture make the code far more difficult to understand and maintain—forever—while perhaps yielding negligible benefits. We’re talking about continuing (and even rising) costs, notably those resulting from complex security flaws, long after the savings of reduced machine workload have shrunk to insignificance. In fact, in modern machines, various methods of “speculative execution” treat computation as being so nearly free that we can perform several different versions of our work, while we wait to find out which one is actually going to be useful – and then simply discard the rest of the results.

If we code for maximum understandability, the savings rise as programmers become more costly and the costs shrink as machines get faster. That’s a good pair of trends. One wonders, though, if our brains are getting any better at seeing (let alone exploring and adopting) such heresies. We’re taught not to waste what’s in front of us now: the marshmallow on the table is real, while the two marshmallows that we might get later are hypothetical. We’re generally not very good at envisioning change in the future, especially change that happens at exponential rather than more easily imagined rates.

Stop unseeing the idea of “good enough” answers

Another opportunity for radical change of viewpoint is the question of “correctness” of results. When we get even the slightest deviation from the One Correct Answer, in the digital world, it’s literally headline news, as Intel learned the hard way with its Pentium FDIV error in 1994. Imagine, then, the discombobulation of an engineer twenty years later encountering MIT’s “Chisel” technique that explicitly trades off accuracy for improved power efficiency. “The researchers tested their system,” reported an MIT press release, “on a handful of common image-processing and financial-analysis algorithms, using a range of unreliable-hardware models culled from the research literature. In simulations, the resulting power savings ranged from 9 to 19 percent.”

We learn to estimate results to sufficient accuracy in our early years of schooling, and then apparently unlearn this idea when we grow up and start treating any error as a bug. Talk about an opportunity to re-enable our vision of the world.

As far as the eye can unsee

Compute cycles too cheap to bother conserving, if we can make the code easier for someone—someday—to read and understand. Answers that need not be “right” if they are good enough, and if the approximation puts some kind of ceiling on computing’s skyrocketing power demands. We’re just getting started.

What about “infeasible, extravagant” databases that never delete…anything? What about…if I knew how to finish more sentences like that, it would mean that I’m already (finally) seeing things that I’ve spent a lot of time and effort learning to ignore.

What are you ready to stop unseeing, and start improving? While that’s still an original idea?