Tuesday, November 03, 2009

When does technology pass from being a tool to being a crutch?

Wow. Yesterday’s post gathered quite a bit of commentary. Most of it on MyFaceSpaceBook (which is copied below for those of you who aren’t using MyFaceSpaceBook) but there’s also some discussion over at Flutterby™!

The MyFaceSpaceBook comments. Jeff Cuscutis wrote:

I think that is a flawed question. A crutch is a tool. It helps you do something you wouldn’t be able to do otherwise.

Every tool since the first stick and rock are crutches. Before books, people memorized enormously long stories regularly. Who does that now?

The difference between a tool and a crutch is when you forget you are the master of the tool and follow it blindly.

Okay. I was using the term “crutch” in a derogatory manner since I don’t have a better term for what I’m describing. Some programmers (and I’ll admit to being in this class) often view using a debugger as a “crutch,” blindly single stepping through the code because they don’t understand the very code they’ve written! (I used to upset other students in college by just looking over their code they’re writing and pointing out bugs left and right). Sure, I use a debugger. But not all the time, and sometimes, a debugger isn’t enough to solve the issue (race issues with multithreaded code is nasty like that).

But I do like Jeff’s last line there.

Chris Monahan pretty much nails what I was trying to get at with asking that question:

I would argue that a tool is serving as a crutch if the task it enables you to do is one that you should or would, under healthier or more ideal conditions, perform as well or better without the tool.

That “should” is a very important distinction. A programmer should be able to reason about their code and at least formulate a hypothesis as to why the program crashes (just beyond the stock answer of “it’s buggy”). The debugger is there to help them prove or disprove the hypothesis and quickly drill down to the actual issue, not to get around the fact they don’t understand the code they’ve written.

Anyway, Chris’ wife, Mary Monahan replied to a comment I made about IDEs:

Who finishes first with an output they can use? Generally speaking a person who doesn’t need the IDE (let’s go ahead and use the common name “dinosaur” :) ) can finish faster using the IDE than the text editor because they don’t have to spend the time visually scanning for typos, etc. A person who can’t use the text editor will be slower than the dinosaur because they are not only using the IDE for simple checks but to generate code, time to debug the generated code they don’t understand, and look up examples, etc. This is not a question of whether the IDE is a tool or a crutch, it is a question of whether a person is choosing the right tool to be efficient and has the skills to do the job in the best way. I have created programs using bit switches, card input, text editors, and a wide variety of IDEs. That pretty much puts me solidly in the dinosaur category for a lot of people. But, if you are using the best tool for the job and you can get it done at the same rate or faster as another person it isn’t a crutch—it’s the right answer.

And Chris’ answer to the same IDE comment:

The question becomes “does the IDE extend or improve your normal capability to program?” If it is something that simply makes up for a lacking that someone has—a lacking that a normal or even robust person would not have, then it is a crutch. If it is something that extends the capabilities of a person beyond what a healthy or robust person could do without the tool, it is not a crutch. Even when talking about an actual physical crutch, if the person uses it to facilitate walking while they are injured and while they use it they walk no better than when they were healthy, then it is a crutch not only by formal name, but also in the abstract. If the person uses the crutch to perform acrobatics they couldn’t otherwise do, then while it physically a crutch, it is not being used as such in the abstract—but rather as a tool that extends their capabilities. The improvement could be in speed of delivery, quality of the final product—any kind of improvement.

For some reason, Chris’ comment reminded me of Oscar Pistorius, who’s taken crutches to Olympic heights, literally. And after that, I don’t really know what to say.

My old college friend Charles Wheelus piped in with:

As our need to work with various types of information becomes increasingly complex, it becomes necessary to work with higher and higher levels of abstraction. Imagine a world where everything had to be programed in assembly language.

Clearly there is a need for the people who "don’t really care how it works underneath", as well as those who do.

The revolution we are experiencing is for every one who chooses to participate, not just those who poke bits well.

What may be a “crutch” from one persons perspective is simply how someone else accomplishes their goal. I don’t think it should bother you just because someone solves a problem differently than you do … even if your way is better.

Well, I don’t think I’d mind a world where everything was programmed in assembly (which was my daily programming language of choice in college). But I do get his point. While I hate PHP and only use it under duress, I can appreciate that it brings a simple programming platform to people who would otherwise be unable to program a dynamic website.

I just don’t want to work with the resulting code.

There is another issue though, with the people “who don’t really care how it works underneath,” and Mark Grosberg said it succinctly (in email):

The future is going to be really funny as more and more people who know how everything really works get out of the field.

Sigh. Welcome to the future!

Perhaps a bit pessimistic, but yes, it is a valid concern I have (as well as Mark).

You have my permission to link freely to any entry here. Go ahead, I won’t bite. I promise.

The dates are the permanent links to that day’s entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that’s intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It’s an experiment in using color shading to denote the distance a link is from here. If you don’t notice it, don’t worry; it’s not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.