How should educators ensure their curriculum remains relevant over time?

Question

I'm sure we can agree that there are some parts of theoretical CS that are unlikely to change - topics such as computation theory (Turing machines, automata) will be useful and applicable for many years to come, [or at least until quantum computing becomes hugely pervasive]! I think a strong theoretical base is extremely important and I greatly enjoyed the modules I took at university which covered this sort of theory.

Most courses do include a practical aspect, though. One of my frustrations as a student who started at university with experince in professional software engineering in industry, was that a lot of the more practical content was incredibly outdated, not in line with industry best practices or just downright irrelevant.

As a concrete example, I took a web development module in 2015 which focussed on PHP 4, taught us to write code riddled with XSS, CSRF and SQLi vulnerabilities and didn't place any emphasis on architecture design. Some parts of the course were useful (such as the primer on how HTTP works at a protocol level) but it was obvious the same slide deck had been reused year after year and I came away feeling like I'd wasted my time. Some of these details seem to be out of the lecturer's hands and determined by the department, but the end result is still the same. I do realise web is perhaps one of the worst areas for this, but it's equally applicable when e.g. introducing Java and not covering the "new" generics support, or the more functional features in Java 8.

What can educators do to try and prevent this from becoming too big an issue? I think trying to keep up with each new shiny JavaScript framework that becomes momentarily popular is unrealistic and useful for neither student nor educator - but there must be some middle ground. Should these sort of modules be entirely theoretical to avoid this problem, or perhaps collaboration with industry could be sought out to explain how things really work in practice?

Answer 1

I see you are in the UK. I think the constraints are different in different places and at different levels. But most of the examples you give are of the ephemera of computing - current languages, frameworks. That may be a misplaced focus. There are other topics, more fundamental, that increase in value over time: encryption, quantum computing, Big Data, Massively Parallel computing, etc.

You need to teach within some current framework, of course, but also to think about how you are preparing your students for taking a wider view. I used Java/Eclipse for a long time, but realize that it wasn't a "forever" solution. I don't think I really did enough preparing for the day when Eclipse won't be available (or desirable), however.

But one concrete thing you may be able to do, subject to constraints, is to have one "Over the Horizon" course, named that, perhaps, or "Bleeding Edge Computing" maybe. It covers the latest and greatest even if you know that the topics may not have the legs to last. A more boring name, but probably a good focus, is "Current Trends in Computing." Students are warned in such a class that this may seem "cool" today, but "cold" tomorrow.

A second thing, not quite the same, is to rotate a series of courses on the rising but likely important things, as listed above, that you can't justify putting into the curriculum as a continuing course. Big Data one term, Quantum Computing the next, etc.

The second solution is much more work, of course, since the course development is harder and maybe won't be amortized over several years.

A third choice is just to let one Prof (in rotation) teach whatever he/she think is the most interesting thing they know and work on. "Professor Williams' Current Research" or something.

As for yourself, go to a lot of conferences (constraints again). Visit the real world when/where possible to see what goes on in the trenches. See what is going on now. Experiment a bit as time permits.

Answer 2

As a wise man once said, "We are preparing students to solve problems that don't exist / using technologies that haven't been invented."

I agree with alephzero in the sense that you can't avoid this issue. Every sign is that technologies will keep changing rapidly, at least for the foreseeable future.

This is why we must always keep our instruction oriented towards concepts, not languages. The syntaxes for arrays and lists will differ in different languages, but the trade-offs between the two remain the same.

One easy way to keep the emphasis on the conceptual is to utilize more than one language. Over the first 3 years of our major, all students work in Python, Java, C, 6502 Assembly, and Scheme. Additional languages are used for electives, depending on the nature of the course content. By providing a more varied exposure, students can easily come to differentiate the underlying concepts from the syntaxes of the languages they are learning.

Answer 3

Educators have to agree that's we're teaching skills, not technology. Reaching that agreement is harder than you might think. It's especially hard in the web-development area. (Disclaimer: that's distant from my area.) What are the key questions or skills that have lasting value? Here are some speculations:

• What does it mean to split a computation between database, server, and client-side browser?

• How do you manage the cost tradeoff between fast loading (which means don't bloat your web pages with scripts and frameworks) versus rich interaction within the browser (which requires some sort of scripting)?

• In five years, new languages/tools/frameworks will be fashionable. What are the skills needed to work with a large API, continually changing, and too complex to master? (Good luck with that one.)

In my own area, programming languages, I don't have to speculate. I know that the important things are functions, types, and objects (maybe also modules). I am confident that in thirty years, these things will still be important. And I can teach these things without using the latest technologies: Scheme, ML, and Smalltalk were all known and usable in 1980. The newest "technology" I teach is actually the math (syntactic methods of semantics popularized around 1995).

What you don't see here are the traps avoided. I don't have to worry about teaching currently fashionable languages like Swift, Rust, or Go. I don't have to worry about whether I am teaching the "right" version of Python. To avoid this trap, I had to do an enormous amount of intellectual work. Such work may not be rewarded, as universities tend to focus their rewards on research.

A final trap for educators: in the US at least, courses focused on timeless skills are much less popular than courses focused on currently fashionable technology. Many students are short-term optimizers, and they want something they believe they can use.

Answer 4

I think about this question a lot. I agree that, if faculty are teaching things close to their research area, then courses should be naturally updated. The issue is: what do you do if your department has no one in a certain research area, but still wants to offer courses in that area? A similar problem comes up in Buffy's answer: who is going to teach the "Bleeding Edge computing" course?

You can ask some poor junior professor to try and develop a course on new things where no one has expertise, but it's a huge amount of work for that person, and doesn't solve the problem of the course becoming outdated as that field develops. I say "junior professor" because a senior professor seems less likely to do course development like this, because they have families, they have administrative responsibilities, etc.

The person who develops the new course can, of course, go to lots of conferences and maybe even give up part of their sabbatical to learn more about the topic (e.g. by working at Google). But that just makes the burden on this person even greater. I think this problem can only be solved with help from the administration. Specifically, I think CS faculty should have a lower teaching load than faculty in other parts of campus, to make these kinds of curricular renewal a real part of their job. Otherwise, it's too tempting to just develop the course once and teach it the same way forever (as folks in many other departments seem to do).

Answer 5

Basically, you can't, unless you have some teaching staff who are actively involved in industry.

Anybody who has spent say 10 years working their way through the academic system from undergraduate to lecturer is at least 20 years out of date, and probably more like 30 years: 10 for their time isolated from the "real world" in academia, plus another 10 or 20 because what they were taught as an undergrad was out of date when they were taught it!

(This may also explain why so much terrible code, and so many terrible textbooks, are written in academia - but that's a different issue!)

I suspect this problem is basically incurable. As a working programmer, I have lost count of the number of languages I've learned (and mostly forgotten again!) over the decades, but it's about one every 18 months on average. I don't see any way that a teaching organization could handle that pace of continuous change.

Another significant difference between industry and academia is that the people constantly learning "new stuff" in industry aren't learning it because they want to say up to date with the latest research. They are learning it because they need to use it. For all I know, the next language I need to learn might be COBOL, to understand some legacy system! In the past I've had to learn enough ALGOL 68 to understand some algorithms in an old published paper, at least 30 years after the language was effectively dead and buried!

Answer 6

One way is to have an industry advisory committee consisting of alumni or friends of your institution. (I was on such a committee for a community college when I worked in industry.) Once a year, the committee meets with faculty to learn about the current curriculum and suggest changes based on their active professional knowledge of the field.

Another way is for faculty members to spend sabbatical years in industry. I learned more about software engineering from a year at Google than from my entire formal education.