All “Features” Great and Small

The last two days I’ve been moving offices. Our unit, which has offices scattered around campus, gained more space in the building where my office is, because most of the Computer Science department has moved into the new Seibel Center. For better esprit de corps we’re moving divisions that had been housed in remote locations into my building. And to best utilize the total space that we have, we’ve reassigned offices to many in the building. That means a lot of people are moving. I’m one of those.

All this makes sense for the greater good of the order and I understand that. But I didn’t want to move. It’s a pain. Two days in a row I’m all sweaty from carrying boxes (and this is with the help of movers) and I don’t know where my stuff is. I screwed up an important budget document because of the move and I’m mad at myself for that. I still fell disoriented so I wouldn’t be surprised if I make more blunders in the next couple of days. Why couldn’t I stay in my old office?

And why, you might ask, am I bringing this up? It’s uncouth to talk about such things --- chin up and all that rot. The answer in this case is to use it as a way to frame the issues. Most all of us have, upon occasion, endured a move. Some of you probably managed it better than I have, but it is an inconvenience for all of us, one we can recognize as such. I want you to keep that thought in mind but now consider another setting, where your campus has upgraded its version of the course management system it supports, or even worse, switched to another platform.

Many of us who support educational technology don’t go through agony when systems are upgraded. In fact, we may be positively disposed to playing with the new version of the software – it’s fun learning the stuff and checking out the new or improved features. But it is really different for our faculty. Their reaction, in the main, will be like mine has been in making the physical move of offices. They won’t like it. They’re apt to be resentful. They’ll want to know whether they can stay in the old version, first off, and then use that to make us feel guilty when they ask what will break in their course site when they have to upgrade.

This may seem melodramatic, but I don’t think I’m overstating the situation. Once a piece of software seems to work and the user has adjusted to it, most users don’t want the software to change. Why should they? The benefits from the change are amorphous to them. The costs are quite obvious. And most faculty are incredibly time squeezed that contributes to their frustration during the upgrade period.

So why is it that in educational technology we support providers push so hard with the vendors or our own developers on coming out with additional features of the software and improving on existing ones? Are we doing it for the benefit of our instructors? Or are we doing it to please ourselves and indulge our too idealistic beliefs about using the technology as a vehicle to improve instruction?

Certainly more frequent change in the software that is supported raises the total cost of ownership. There is more work needed for providing documentation, more training and more follow up consultation for instructors. There are more chances that the configuration of the production system gets screwed up or becomes inappropriate or that some particular unsolvable bug is uncovered.

Here are a set of arguments for why I continue to ask for new features on the instructor side of the product.

Our User Base (To Every Thing Churn, Churn, Churn.)

I don’t think it is commonly recognized that there is a lot of churn in the use of course management systems, at least there is a lot of churn on our campus. We have many instructors who are graduate students and adjunct faculty and those people turn over quite quickly. Also, tenure track faculty instructor rotate between graduate courses where they likely won’t use the CMS and undergraduate courses where they will.

This means we have a substantial population who are new to our system each semester or who have been away from the system for a while and are coming back for a fresh start. While most of these people don’t want to spend a lot of time learning something new, they do want to be assured that the product they are using is current and up to date.

Staying Current with Other Software (Blame it on the other guys.)

Even if we don’t upgrade our CMS, the browsers, plug-ins, and other software our users rely on will upgrade by processes that we don’t control very well. Our stuff has to work with what they have. We can’t guarantee that it will if we get too far behind in what we are supporting. Thus we need to keep up.

Moving Down the Technology Learning Curve (Teaching the Old Dogs New Tricks.)

As instructors get comfortable with using the CMS some of them begin to see possibilities for improving their course and they want to try new things. (We really do need to know how many are in this category and what type of things might encourage this. The ECAR study by Glenda Morgan from a couple of years back suggests that this population is not as large as we might like.) At the point where they are ready to try something, we should be in a position to provide a set of possible offerings. We want new features so we can do just that.

Improving Instruction (I’m the guy your mother warned you about.)

This is why most of us got into the business. We are there to make the learning better. Any improvement in the software that has a chance of doing this we should champion. Here what we really want to do is promote the teaching idea. We don’t expect the software to do it all by itself. We expect the software to serves as a catalyst for the teaching idea and as an instrument to implement the teaching idea.

Let me explain the parenthetic remark in the header, which might otherwise seem obscure. This one is the purest of motives. And clearly it drives us. But perhaps we place ourselves in the role of teacher too much rather than focus on the typical instructor. Keep in mind that the track record on innovation with learning technology by tenured track faculty is spotty at best. So we push for innovation that may be anti-utilitarian. We raise expectations and costs this way and may produce a lot of disappointment. In terms of less uptake than anticipated. Is this the way a twenty first century manager should show leadership?

Competition with Peers (Satisfying our Insecurity Complexes by Keeping up with the Joneses.)

This is a less pure motive but it may be more primal in explaining our behavior. Over there at Peer U, they’re supporting a different CMS than we have here. It has some really cool features that their tech folks say their faculty absolutely love. We better get those, and soon, or we’ll look like slouches and our faculty will complain that we’re falling behind.

- - - - -

Taken together, this is not a bad list of reasons. It is not entirely uplifting to be sure, but most of the reasons are defensible. The thing is, if you reflect on them for a while you likely will conclude that while some innovation in the software is a good thing, the pace of change that we advocate for is probably too rapid. We know Microsoft turns over its product offerings quite regularly, perhaps on a biennial basis. And we know why they do it to. (Non-economists who want to impress their friends can refer to the Coase conjecture about how a durable goods monopolist will end up pricing at marginal cost.)

But we aren’t Microsoft and we should know better. That the vendors push innovation on us, might be understandable. But that is not my experience. We, the informed users of these products, are incredibly demanding in what we want to see in them. This is something for us to ponder.