Computing at odds with getting Faster

June 2, 2010 at 11:14 pm 8 comments

I just finished reading James Gleick’s book Faster: The Acceleration of Just About Everything.  It’s a 10 year old book now, but the story is still valid today.  I didn’t enjoy it as much as his books Chaos or Genius. However, the points of Faster are particularly relevant for computing education.

One of Gleick’s anecdotes was on how AT&T sold Touch Tone dialing in 1964 as saving an average of ten seconds per seven-digit number dialed.  Now, we have speed dialing.

In the post-Touch Tone generation, you probably have speed-dial buttons on your telephone.  Investing a half-hour in learning to program them is like advancing a hundred dollars to buy a year’s supply of light at a penny discount…To save time, you must invest time.

Do some students and end-user programmers invest time in learning to program to “advance a hundred dollars to buy a year’s supply of light at a penny discount”?  Are they looking to program in order to save time, to do things faster and more efficiently?  Do they give up on learning to program when they realize that it doesn’t work that way?

The problem is that I don’t think that ever really happens for the individual writing code for him or herself.  It’s hard to program.  The time cost of programming amortizes over users.  The development cost of Microsoft Office, amortized over millions of users, results in a profit for Microsoft.  A few hours of a programmer’s time on some feature of Excel enables many hours of use of that feature by many users.  But for any individual writing code for him or herself?  Takes a lot more than 30 minutes of programming software to get the same usefulness of 30 minutes of programming speed-deal buttons.

So why program?  In the Media Computation Python CS1 class, we tell students that they should program in order to create a replicable process (if you need something to be done the same way, maybe by others, many times), to create a process that many people can use (like when commercial software is created), or to communicate a process (like when trying to explain a theory of how something dynamic happens, like DNA transcription or evolution).  Paul Graham tells us that hackers write software to create beauty.  But few people successfully program in order to save time for themselves — you’d have to do something many times to make the benefits of use outweigh the cost of development.

Maybe it shouldn’t be that way.  Maybe software development should be easier.  I wonder if you could make it easier, and still keep all the fun, all the communicative power of programing languages, all the “Passion, Beauty, Joy, and Awe“?

The overall story of Faster may be relevant for understanding the decline in interest in computer science.  Gleick claims that “boredom” is actually a modern word and concept.  “To bore meant, at first, something another person could do to you, specifically by speaking too long, too rudely, and too irrelevantly.”  Today, we are bored by simple silence — by not enough challenges, not enough multi-tasking, by too many choices.  We have so many options for entertainment that we choose many at once, so that we drive, while listening to the radio, and talking on the cell phone (not texting or doing email, of course).  Gleick (naturally, as an author) bemoans the death of the book, because readers are too easily bored to pay attention to a whole book, and always have the options of magazines or blogs or just 140 character “tweets.”  Why would anyone make a career choice like “computer science” when there are so many other choices that are less boring, take less concentrated focus, take less time?

Gleick provides an afterword for the electronic version of the book (I read it on my Kindle), where he speaks to some of these concerns:

I believed when I began Faster, and believe now more than ever, that we are reckless in closing our eyes to the acceleration of our world. We think we know this stuff, and we fail to see connections. We struggle to perceive the process of change even as we ourselves are changing.

Tags: ,

Powered by Qumana

Entry filed under: Uncategorized. Tags: , .

How to help professional teachers share their practice Evaluation as a Voice for the Kids in the Back of the Room

8 Comments Add your own

  • 1. Alfred Thompson  |  June 2, 2010 at 11:37 pm

    I once wrote a program quickly and dirty to solve a particular problem. Basically I needed something to be done that was impractical to do any other way than by having the computer do it. So that, making the otherwise impossible or impractical, easy is often one good reason programs are written. The program was a mess and was very slow so I thought about optomization. I stopped and estimated how much time fixing it was likely to save me over the course of a year against the time it would take me to fix it and decided (rightly I think) to let it be. Six months later a new and faster computer meant the program was now fast enough not to annoy me anyway.
    Note that in general assuming that faster hardware will fix poor software in not in my opinion a good way to think. In fact it is very harmful but I digress.

  • 2. Erik Engbrecht  |  June 3, 2010 at 12:05 am

    I’m going to strongly disagree with your Excel example. I work with a non-representative sample of people, so you can take that for what it’s worth. But if someone puts invests a few days in learning to program Excel, then they can easily save themselves countless hours of labor by doing a little programming. The same goes for SQL.

    There are a lot of people out there who aren’t programmers but whose jobs entail a lot of repetitive data manipulation. A significant minority of them will learn basic VBA and/or SQL in order to save themselves time.

    “Real programmers” tend to expect to write a program that takes some inputs and fairly consistently yields a complete and correct answer. These other folks will readily accept the fact that their program gives them something that is incomplete or even wrong, but manually fixing what is wrong takes a lot less time than starting with the original inputs and manipulating them manually. Even programs that sometimes utterly fail can be useful is they work sufficiently well enough of them time.

    Also, “real programmers,” especially computer scientists, tend to have a much stricter view of correctness. Often times people want to aggregate information in a way that is blatantly incorrect if one takes a strict view. But they can do it by hand and get something close enough, and often they can speed up the process with some macros. The computer scientist’s view of correctness never comes into play. It’s not even close. The type of “algorithms” real world information workers will apply, whether manually or with the support of some automation, are enough to make a computer scientist want to run screaming for the hills.

    Think about how much bad, buggy software there is out there. Stuff that doesn’t work. It randomly crashes. It yields inconsistent results. It’s hard to use. And I’m talking about professionally developed software that’s been through format QA processes. If real users really cared about correct results and consistency most software in use today would be completely unacceptable. But they don’t, because they have no idea about these things. All that matters is that it’s better and/or cheaper than a person would produce by hand, and frankly that’s an extremely low standard. Hence the glowing success of an industry that, but the standards its professionals learn in school, mostly produces absolute junk.

    • 3. Darrin Thompson  |  June 3, 2010 at 2:55 pm

      My brother, a newly minted MBA, got himself into business analysis by building up a great deal of expertise in “programming” Excel and learning how to hook it up to real databases to figure things out for his employers. The MBA lets him actually get paid for it now. (nice work bro)

      If you think of a spreadsheet (not counting a “macro” or scripting system) as an incomplete lazy functional language with a limited practical domain, maybe we’re closer than we think?

  • 4. Tony Hursh  |  June 3, 2010 at 9:20 am

    Raw time isn’t the only important metric. I suspect that many of us have elected to write code rather than carry out some mind-numbing, repetitive task — even when writing the code was a net time loss. Programming is fun. Hours of copying, pasting, and reformatting by hand is not.

  • 5. James Howison  |  June 3, 2010 at 11:04 am

    Interesting, as always 🙂

    Introspection tells me that I sometimes program something I could do by hand faster because I’m procrastinating from a) the mind-numbing repetition (as @ Tony Hursh mentions) but more importantly b) not being sure what I’m going to do next. Turning an intermediate step into an interesting problem turns a big hairy problem into something that’s tractable. Of course it puts off the inevitable 🙂

    I’d add to your reasons (or augment your replicability/explanatory reason) by saying that anything you’d need to explain to another you need to explain to yourself in 6 months time. Particularly important in research.

  • 6. Mark Guzdial  |  June 3, 2010 at 12:52 pm

    That was definitely one of my less clear blog posts (perhaps I should avoid writing under the influence of jet-lag and a tropical climate). @Erik, you’re absolutely right that a tool like Excel makes programming into an activity where the benefits outweigh the costs for individual’s goals. I was more addressing myself to the programming that a CS major might do (or that an end-user might stumble into) in a traditional commercial language (C, C++, Java, etc.). Part of the problem is the weaknesses of those languages! But within that paradigm, the costs of development usually outweigh the time benefits for the individual — that may be a shock to our students. As @Tony and @James point out (and as I mention in the paragraph referencing Paul Graham), there are certainly other reasons to program. Discovering those for oneself inspire students to what I think Alan would call “real Computer Science” — finding the joy in expression, in figuring things out, in trying to invent better. But if your goal is to be “Faster,” current CS practices and classes won’t be much help. Maybe we get buggy software (as I think you’re suggesting @Erik) because of developers not being interested in the deeper parts, only being interested in being “Faster.”

    • 7. Darrin Thompson  |  June 3, 2010 at 3:01 pm

      Just don’t dismiss Excel out of hand. Millions (probably not quite billions) of non-programmers have written computer programs with it. Maybe “addressing myself to the programming that a CS major might do” is precisely why we make so little progress.

      Maybe there are a series of intermediate forms we need to pass through to be able to see what faster “real” programming would look like. Spreadsheets might just be one of the early forms.

      For instance, another one that is interesting but hasn’t really taken off is Ruby Shoes.

      I like that this project tries to make programming more tractable by limiting the domain. That seems like a productive line of research.

  • […] is that it’s about directed conscious attention to sense-making. Computers today are about multi-tasking and avoiding boredom. Boredom isn’t nearly as dangerous as ignorance. Kay says the education system has squandered […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,052 other followers


Recent Posts

Blog Stats

  • 2,031,460 hits
June 2010

CS Teaching Tips

%d bloggers like this: