As another academic semester draws to a close this month, I feel compelled to share some thoughts about how traditional institutions of higher learning are failing to train engineers and computer scientists to become embedded programmers.
Writing software for embedded—particularly safety-critical or real-time—systems is not easy. Many folks with a degree in computer science or engineering will never be qualified. A deep understanding of computer hardware and specific I/O interfaces and devices is one requirement. Knowledge of and experience with programming techniques that hold up under soft or hard real-time deadlines is another. Willingness—even eagerness—to debug difficult interactions between software and hardware with limited visibility into a system is an absolute must.
The subject I teach, operating system internals, deals with some of these issues. I expect the students in my course to gain an understanding of real-time scheduling, multithreaded programming and synchronization, and device driver writing. These skills would serve them well as embedded programmers—but one course is not enough to make them such.
Most of my students arrive with only a limited understanding of computer architecture! It’s unbelievable, unless you’ve seen it first hand, that the bulk of a group of graduate and senior undergraduate students studying computer engineering don’t understand basic concepts like stack frames, interrupts, DMA, and cache. It’s not that they haven’t heard those words before; rather, they don’t have any first-hand knowledge and, therefore, lack understanding of these extremely important concepts.
This is symptomatic of a larger problem with engineering education in general. Engineering students are not currently challenged in the right ways. They’re challenged to understand computer architecture without designing a computer. They’re challenged to understand operating systems without writing one. And they’re challenged to understand (and write, in my class) multithreaded programs with only one freshman course in basic C programming behind them.
This is symptomatic of a larger problem with engineering education in general. Engineering students are not currently challenged in the right ways. They’re challenged to understand computer architecture without designing a computer. They’re challenged to understand operating systems without writing one. And they’re challenged to understand (and write, in my class) multithreaded programs with only one freshman course in basic C programming behind them.
Why aren’t engineering departments challenging their students to be engineers? Engineering is the practice of science. Students are taught the basic science well: math, physics, chemistry, etc. But they’re not taught the practice. By the time they get to their junior year, and throughout grad school, all students should be required to work on real projects—every semester, in every course. A little assembly and C programming here, a CPU design there, and some hands-on DSP work could go a long way toward preparing them for the world of work.
Without that first-hand experience—and I know that’s not just lacking at the University of Maryland because my graduate students are mostly from other schools—these folks just plain aren’t useful as engineers. Among the poor and outdated requirements for accreditation of engineering degree programs is a recent innovation that seeks to address this problem. In their senior year, all undergraduate students are now required to work on a “capstone project”. This involves working on a small team, with the assistance of an advisor, on a project of their own choosing.
While the capstone project is certainly a good idea, it’s also too little, too late. Because students working on these projects haven’t had any practical experiences before, they rarely succeed in achieving much of anything. The capstone should be part of the end of the program, but it should also be the last in a long string of practical projects—in all manner of courses along the way.
