Rendered Fat Content

Thinking Like A Computer

“The problem is not that computers might someday think like men, but that men will learn to think like computers.” Sidney J. Harris

In the early sixties, Heintz von Foerster founded the Biological Computing Laboratory at Champaign-Urbana. Over the following fifteen years, fueled by enthusiastic inquiry and heavy Defense Department funding, von Foerster attracted a remarkable collection of scientists to investigate how a computer might be engineered to think. It had been barely a generation since Turing had originally imagined how a machine might be enabled to reason, and this next step seemed, well, only reasonable at the time.

These scientists shortly encountered a class of problems which they labeled “fundamentally undecideable,” and from that discovery grew the eventual demise of their grand plan for a thinking computer. The field of Artificial Intelligence grew out of BCL’s work, but has yet to resolve the fundamental undecidability dilemma.

Today, we employ computers to accomplish tasks unimagined by the BCL, but we have not yet managed to create a computer capable of anything more than rapid reason. Our metaphors attribute thought, even wisdom to our machines, but they are capable of neither. At best, they can fuel insight impossible without some very rapid reasoning. They can assume the burden of many menial, literally mindless operations, freeing us up to sometimes think more clearly and productively.

But thinking more clearly and productively depends upon us retaining our native abilities, and not merely mimicking our computers’ marvelous memories and mindless operations. We cannot simultaneously think like a computer and retain our fully human capabilities to think.

Fundamentally Undecidable Problems

My sister has a degree in Performance Arts. She can sight-read piano music, yet she cannot interpret the music I write. This is reassuring to me, because while I have no degree in music, I write songs. But I’ve always stumbled when expected to transcribe my music into notation. I thought I had this dilemma resolved, finally, when I found a piece of software capable of transcribing, via a MIDI interface, my keystrokes into musical notation. So I wrote my sister a song for her birthday, performed it for her, and promised to send along the notation so she could recreate the melody whenever she wanted.

Two weeks later, a sheepish note came from my sister. “I warmly remember you performing that song for me on my birthday, but I just cannot recreate that feeling from the notes you sent. Thanks for trying, but I think I’d rather just hold the experience as a memory.”

This was a relief to me. I discovered when I tried to transcribe the melody that the metronome got in the way. When I perform, I quite naturally slow and stop, speed up and embellish, and the metronome’s click-click-click distracted me. My first result read wooden and lifeless. Then I turned off the metronome, following what’s called atonal transcription (which in this case was really a-rhythmic), and found little relationship between what the resulting measures so carefully and precisely enumerated and the flow of the song. The transcription software tried to fit what I played into a rational framework, and even succeeded, but the number of slurs and sixteenth notes told me that, while the melody had been captured, it looked like a nightmare on the printed page.

I remembered a question from Prigogine’s work on complex systems. How long is the English coastline? Prigogine decided that the length of the English coastline is infinite, depending upon the scale chosen to represent it. If that scale was large, the length could be resolved into finiteness, but at the cost of usefulness. If that scale was very small, the accuracy increased but also at the cost of utility. Who could ever fold a map where the scale is one micron equals one inch? Further, the tides changed constantly, which meant that there, in a very real sense, could be no provably accurate calculation of the length of the English coastline, absent some arbitrary assumptions.

Prigogine concluded that the length of the English coastline was arbitrary, a function of chosen assumptions. Precision was beside the point. The question was fundamentally unanswerable.

The same thing happens when transcribing music. The songwriter must divorce himself from the originating inspiration to satisfy the rules necessarily constraining transcription. The result, absent inspiring interpretation in performance, is a wooden, logical representation. Exact but lifeless. Muzak®.

I own several different recordings of the same piece of music. Each different. Each very much the same. The score behind these differences is the same rational transcription of the composer’s original inspiration, worthless except when infused with human interpretation. If I were to judge each performance by the degree to which it followed the original score, I would be thinking like a computer, not like a man. When I appreciate the differences, even those which seem quite different than I expected, I think like a man, not a computer.

Projects started employing computers before most present project practitioners were born, and well before the BCL stumbled onto the principle of fundamental undecideability. When I first encountered these scheduling engines, we still fed them with punch cards. I remember engaging enthusiastically, with the same redemptive spirit that I recently brought to transcribing my music with the MIDI interface, because I imagined all of the time I’d save by having the computer complete the many mindless calculations.

I remember my mentor at the time counseling me that if I couldn’t calculate the critical path by hand, the machine wouldn’t be much help. I didn’t completely discount this comment, but it didn’t blunt my enthusiastic first thrust into computing. So I painstakingly coded task durations and relationships onto a deck of cards, submitted them to Operations, and waited for the resulting printout. How very similar was my experience reviewing that first schedule printout to my more recent experience with musical transcription.

My reasonably accurate representation of that task series transcribed into a gawdawful mess! The machine had smoothed resources to show logical availability, utterly changing task sequence and overall duration. Click-click-click. Only the metronome was missing.

So I reworked the task series, this time anticipating the computer’s logical smoothing, and reran the card deck until the results sort of almost resembled my original intentions. It didn’t occur to me then, but the computer was teaching me to think like it thought, even though the computer never had an original thought in it’s ... er ... life. It wasn’t alive or thinking, but rationalizing.

I would be alive, or could be alive, unless I learned to think like a computer. The choice was not clear at the time, but something very like my songwriter’s distaste for transcription bloomed in my belly. Sure, I worked with the scheduling engine, after all, my plans would not be considered fully thought through plans unless accompanied by a pristine printout, but I was not fooled into believing that these transcriptions carried the inspiration I intended my compositions to carry.

The auditors didn’t make this fine distinction. Like cartographers who never actually had to navigate by their charts, they judged the goodness of my plans, not by the passion they imbued in performance, but by how well they satisfied the principles of transcription.

Later, I started managing what were called software development projects. Software is very much a form of transcription intended to instruct computers through rational operations, so I wasn’t surprised when I noticed that the computers and not the programmers were in charge. The computer had the final say, though it was supposed to be in service to resolve some business problem. In practice, the limitations of the computer more often decided whether and how a business problem would be resolved. Why? Many of the business problems these projects were chartered to resolve were fundamentally undecidable problems. Only if reframed into some rational framework could they ever be reduced to solution. Of course, these solutions rarely imbued the spirit intended by those sponsoring these efforts. They asked for music and got a lousy transcription. Muzak®, not music.

The users didn’t appreciate these outcomes, but we worked with them to help them think more like computers. Eventually, helped along by the evolution of colorful user interfaces, most of the dissatisfaction resolved itself into blinking, backlit, trance-like acceptance.

We have evolved into a state where we judge the goodness of our inspiration by our ability to transcribe it. We’ve learned to think like our computers. In a project context, we expend great energy to rationalize our methods, even though in execution, our projects behave non-rationally. Not exactly irrationally, but more like human inspiration at work. Or not. When we are able to squeeze the originating inspiration into a rational exposition, our computer-thinking brains are satisfied, and we might never miss the potential we squash out of the performance. Until we see an exceptionally performing project.

Then we ask after their best practices, innocently overlooking that the practice is never the performance. We might more thoughtfully ask after their inspiration, so we could look beyond their guiding notation and the distracting click-click-click of their metronome to appreciate, if not fully understand, the magic in their performance.

©2006 by David A. Schmaltz - all rights reserved

blog comments powered by Disqus

Made in RapidWeaver