Bad Ideas RevisitedBy Royal Van Horn Illustration © 1998 by Mario Noche | ||
RARELY do I get much e-mail about these columns. In fact, I seem to be getting less every year. I don't know whether this is a commentary on how many people are reading printed material nowadays or an indication that my columns have just been too pedestrian to warrant comment. I have a hunch about the answer, but I will save that discussion for a future column.
As I reflect back on all the Technology columns I have written, the one that received the most e-mail, both pro and con, was the column titled "Bad Ideas: Technology Integration and Job Entry Skills." That column was also more widely reprinted and quoted than any other of my columns.
Before I start this second "bad ideas" column, let me offer two caveats you should bear in mind as you read. First, at heart I am a scientist, and scientists are trained to be skeptical. Over the years, my skeptical nature has caused me to be called "the king's loyal opposition," a curmudgeon, a naysayer, and lots of things unfit to print. I suspect that we contrarians just don't get a lot of fan mail.
My second caveat has to do with a teaching my late father drummed into my head: "If a million people go jump in the lake, it doesn't mean that you should." Always remember that just because everyone around you thinks something is a good idea doesn't mean that you should. Groupthink is not a good thing.
With that said, here are a few bad ideas that lots and lots of people try to foist off as good ideas. I think they are downright dumb, bad, counterproductive, and poorly thought out.
Bad idea number 1: a fixation on processor speed. A computer's speed can be measured by the clock speed of the CPU (central processing unit): a 500-MHz computer is faster than a 400-MHz computer. I recently attended an IEEE (International Association of Electrical and Electronic Engineers) interest group meeting in Arizona. Computer architects and chip builders from such companies as IBM, Intel, and Motorola were in attendance. I knew it was a serious "insider" meeting when I learned that there would be no written record of the proceedings -- even handouts were banned!
At this conclave I learned two things. First, it's tough to build processors with higher clock speeds than today's processors without using a lot of electrical power. This means that PCs must run hotter and that laptops will eat batteries faster. Second, the chip builders now wish that they had not used processor speed measured in MHz to sell their products: it's coming back to haunt them.
There are many reasons why it's a dumb idea to measure the speed of a computer by the clock speed of the processor. The first and most obvious question to ask is "Fast at doing what?" What people really want is a "quick" computer, of course, and the speed of the processor relates only indirectly to how quickly the computer will do what we want it to.
And this fact relates to the second reason why measuring the speed of a computer in terms of processor speed is a dumb idea: there are lots of computer parts that make the machine fast or slow. My personal computer is a good example. I have a Mac with a processor that runs at a meager 200 MHz. However, my computer is one of the fastest in town when it comes to doing multimedia. My computer has some of the fastest hard drives made, and it has a super-fast FireWire (IEEE 1384 interface standard) input/output port that lets me get things like video from camcorders at breakneck speed. There are a few other things that make my computer "fast," but most of them have nothing to do with the processor speed. In the end, the speed of a computer is governed by its slowest component, not by its fastest. That big engine you have in your car won't let you drive fast if you have a wobbly tire.
Bad idea number 2: excessive dependence on user support. Maybe it's coincidence, but lately I've run into a lot of people who have been whining about user support. On the one hand, colleagues and teachers tell me, "I can't do that unless I get some user support." (Often they mean "hand-holding" and a series of training sessions run by someone else.) And just today I was told, "We can't do that with university servers since we don't know if we can build a plan to support it." First, who said that someone else is responsible for your learning to do something with a computer or for helping you if you have troubles? Most people learn to use a computer by actually doing so and not by being taught how. Yes you can learn without being taught. Second, in many cases an institutional support plan is not necessary. Take e-mail, for example. I used to install the software in a school's server and then have mandatory training sessions for the teachers before they were given an e-mail account. Then I ran out of time at a school, so I installed the e-mail software, gave everyone an account, and told the teachers they would just have to learn to use the e-mail system on their own. Within a day or two, everyone was using the e-mail system, and a few of the teachers even knew how to do things that I couldn't do. I could have said, "I can't support the e-mail software, so I guess you can't have it." Dumb idea.
In reality, user support is not an all-or-nothing issue. If I were the supreme administrator in charge of "user support" for a school or university, I would say quite frankly, "There are some things for which we provide a lot of support and training, there are some things that we support to the best of our ability, and there are some things for which we cannot provide much support. But you can still do them if you want to." Let's not squelch innovation and ingenuity just because some corporate policy says we "cannot support it."
Bad idea number 3: the long-range technology plan. For some strange reason, everyone thinks we need a long-range technology plan. Usually this means that we should get a whole bunch of people together, take the average of everyone's ideas, and make a three- to five-year plan for how we should proceed. I am reminded of an old saw, "Nothing in education is ever done until everyone is convinced it ought to be done and has been convinced for so long that it is now time to do something else." The problem with nearly all long-range technology plans is that they are not based on vision, and without a vision, long-range technology plans are just a waste of time.
Nearly three years ago, my late brother Jim, who was the vice president for administration and finance at the University of Nebraska system office, had a vision and told me, "Royal, I am convinced that within six years, universities that have not developed distance-learning delivery systems for many of their courses and degree programs will begin to fold." Subsequently, the University of Nebraska system developed a long-range plan based in part on Jim's vision and awarded a $7-million to $9-million contract to make that vision into a reality. Is the vision paying off? You bet it is. But please don't take this example to mean that developing a vision is easy. I could write a book on how carefully the folks in Nebraska studied everything imaginable that related to their vision for distance education. The point is simply that, if you cannot imagine the future, you cannot go there or make it happen.
Bad idea number 4: leaving people out of long-range plans. Last fall, I spent four long days with a top administrator, describing all the neat projects that people throughout the system were doing or wanted to do with technology. I talked about the online courses that a few faculty members were developing, about an innovative high-tech art project of the art faculty, about the electronic multimedia portfolios being developed by interns, about the grant that had pioneered videoconferencing, and so on. Throughout these discussions, the administrator and an aid took copious notes. These notes were then given to a second administrator, who developed an eight-page spreadsheet chronicling everything we had discussed -- minus a few details. The resulting "state of the technology" spreadsheet did not have the names of any of the people who were doing the innovative work, nor did it directly reference the courses or projects. Now the spreadsheet has been handed over to the school's technology committee so that a long-range plan can be developed.
Bad idea number 4 is not about technology plans or visions; it is about people. Students don't learn from courses, they learn from people. Institutions don't innovate, the people in them do. We do not support the offering of a course via distance learning, we support the people who offer the course. If you are an administrator, I understand your problem. You need to promote the mission of the institution, and naming names is a problem for you. Obviously, you don't want to be seen to be naming favorites, but keeping people out of your plan just won't work. Period. Support people one by one and in groups, and grow the groups. Another way to say this is, support the early adopters and gather others around their visions.
Bad idea number 5: concentrating technology at the center of a network. One of the biggest challenges facing school districts and state university systems is the development of a modern wide area network (WAN) that will provide state-of-the-art technology services and communications to each and every school or building. In the old days, the plan was simple. Put a large mainframe computer in a central location, and let everyone at remote sites have a dumb terminal -- essentially a keyboard and monitor connected to the mainframe. This arrangement didn't require a very sophisticated or high-bandwidth connection between the terminal and the mainframe. All the system had to do was transmit the keystrokes of a user to the mainframe computer. But things have changed.
Now, instead of having dumb terminals at remote sites, we have the equivalent of a mainframe computer on every desk throughout the whole school district or university system. This creates new opportunities for users, but it also creates a lot of headaches for the information technology department. We have more and more computer power in the hands of more and more people, and we have trouble getting it all hooked up and working together on a WAN. The matter is really quite simple. Should we try to keep the main servers in the center of the network so they are easy to manage? Or should we decentralize the main servers -- move them to the edge of the network (to the schools) -- and create possible support problems?
From my vantage point, it seems that most district information technology plans call for sticking closely and often doggedly to a "keep the technology in the center of the network" plan. The glitch in such a plan is that it requires a very high-bandwidth WAN. Furthermore, most districts are trying to create the requisite high-bandwidth WANs using T-1 lines or their equivalent. This just will not work satisfactorily. The administrative system takes at least one-fourth of the capacity of a T-1 line to work, the schoolwide e-mail takes another fourth, Internet access takes half, and a single high-quality videoconference takes another fourth. These fractions add up to more than the total bandwidth of a single T-1 line, and my estimates are very conservative. If you want to keep all the servers at the center of the network, you will probably have to build a higher-bandwidth network than you can afford. The only real solution is to get lots and lots of money and build a really fast WAN. Or you could move the servers to the edge of the network, in order to cut down on the requirements of the wide area network.
If these arguments don't convince you that keeping all the technology centralized is a bad idea, then just consider the Internet. The Internet works simply because nearly all the computer power is at the edge of the net. I assure you that the world's largest WAN, the Internet, would not run as a centralized model.
Maybe this "bad ideas" column won't get the volume of e-mail that I received on the first one, but you can't say that I didn't try! Let me know if you have suggestions for a possible third "bad ideas" column.

PDK Home | Site Map
Kappan Professional
Journal
Last updated 17 April 2000
URL: http://www.pdkintl.org/kappan/kvan0004.htm
Copyright 2000 Phi
Delta Kappa International