I wrote a Student Information system for my midterm project back in 94 written in Clipper and runs on MS-DOS.

I demoed & explained to the panel of professors how it tracks enrollments, payments, class schedules, grades and attendance of each and every student. Has user authentication, auditing and reporting functionalities.
It has a lite version also written in Clipper that can be installed on a Professor's laptop so that he/she can update records even at home, and would be able to sync with the db at school via a BBS. Telix for DOS (self-taught) was my choice for the BBS as it was shareware, has built-in Zmodem support and comes with it's own programming language called SALT (Script Application Language for Telix) that can be used for automating tasks. The lite version of my project would dump the updates on an ASCII file, compress the file using PKZIP, use the laptop's modem to dial-up the number to the school's BBS and send the file across using Zmodem protocol.
The main version would then download the file(s) from the BBS and proceed to do a sync.

After the doing the demo and answering all their questions the panel asked me to wait outside the room, called me back in after 15mins and told me that I don't have to attend that class for the remainder of the term. The happiness as the my classmates outside of the room gawked at me felt like King Midas himself gave my balls his golden touch.

Then in 97, 2yrs after I graduated, I accompanied my cousins to a different campus of the same school for their enrollment and right there on the bottom of the screen were my initials on a very very familiar UI! They actually used, and were still using, my school project. Needless to say my cousins didn't believe that it was written by me.

Professors today in colleges don't know...
.
1. the proper denominations of outputs of basic shell commands like "ls -l", "cat", "cal" (pronounces linux as laynux)
.
2. how memory management works
.
3. how process scheduling actually takes place and not in the outdated bookish way.
.
4. how to compile a package from scratch and including digital signatures
.
5. cannot read a man page properly, yet come to take OS labs.
.
6. how to mount a different hardware
.
7. how to check kernel build rules, forget about compiling a custom kernel.
.
.
.
n. ....

Yet we are expecting the engineers who are churned out of colleges to be NEXT GEN ?!
It is not entirely because of syllabus, its also because of professors who had not updated their knowledge since they got a job. Therefore they cannot impart proper basics on students.
If you want things to change, train students directly in the industry with versions of these professors UPDATED.

Update the method books and lectures, first and foremost. Nothing better than studying outdated versions of languages just because university's technical base can't accommodate anything newer.

Upgrade the universities' hardware and software (I studied CS subjects on 1998 hardware with Windows XP and Lubuntu on board).

For the love of anything holy, stop making students program on paper.

Make professors available via e-mail. A surprising number of my professors weren't teach savvy enough to use it.

Introduce programming in highschool. Use a language that is easier to grasp than Delphi or Pascal. We had informatics as a class, and it never covered anything aside from Microsoft Office.

So far I've been pretty lucky... except for the code some of my professors at uni used in their assignments. A couple of them had this horrid habit of giving you a horribly-written, out-of-date (we're talking these chuckle heads used the same code for years on end and wondered why it didn't work on new versions of Java), messy source file with "fill in the blanks" sections like it was some kind of Java Mad Libs book. One of them had an entire jarchive of data structures we were required to use that he'd written in the '90s and NEVER UPDATED. Another one had a script he'd written for his own specialized assembly macro preprocessor that he'd been using without update for who even knows how long. Now, we were using one of those goofy virtual machines with its own simplified assembly language, and we were on the fourth version of the program. This guy'd written his macro processor in Java for the second version, never updated his Java source, only provided a barely-working .bat script for running it, even though the department's official preference was a *nix environment, and implemented this horrid "pretty-printer" that had a regrettable little habit of eating code. You heard that right. You'd run build.bat and it'd expand your macros then send it over to the pretty-printer which would very infrequently just replace the existing program file with an empty file. When we brought it to his attention, he goes "...huh. never happened to me." and proceeded to use the very same set of programs for the next three semesters, even when the assembly simulator was updated again. I heard wails of anguish from the poor sad souls that came after me as their macro processor created program files with deprecated operations, their pretty printer printed out beautiful, perfectly-organized empty files, and the professor responded to every second of a student begging for an updated version with "...huh. never happened to me." I never saw a single bug reported to either of those professors even acknowledged, let alone fixed. Some of the Java Mad Libs were the same ones they'd started using when they first switched the curriculum from Ada to Java. Thankfully after my first year I escaped into the bliss of the next three years, which were full of *nix and C and beauty.