|For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
A Call for a New Curriculum
Perhaps the reason for this is the simplification of hardware and explosion of firmware. I suspect there are more EEs around than needed. Companies find them desirable for software development due to their deep knowledge of how things work.
But as the firmware's complexity increases it also becomes more like application code. Implementing drivers and ISRs will always require hardware insight, but that might be 1% of a large project. GUIs, net connectivity, and data reduction looks pretty much the same whether it's on a PC or an embedded system.
Some contend that EEs are better problem-solvers than CS folks, due to their analytical nature that spouses find so infuriating. Perhaps. I suspect most of those skills are developed on the job, and not as a result of academia.
EEs do learn an awful lot of software in college. But only in the worst possible way. Few schools stress software engineering; most teach people to write programs. The students I've worked with learned C++ by writing code. "Here's the fundamentals of the language, now write a program to do this." Process is almost unheard of. Nearly none know about inspections, PSP, CMM, XP, or any other disciplined development strategy.
CS majors get more of a sense of these techniques, though for them, too, coding is generally the only thing that counts. They're graded on producing projects, not on how they build a project.
I think coding should be abolished in college, at least until the Junior year. Any idiot can crank code. Stress process early. These folks will mostly be working as part of teams, not as solo heroes. Give them the skills they'll need to be effective team members. Teach them to build big projects reliably. Make them abhor cowboy development.
It matters little which methodology people learn. Teach them to think through implications of their design decisions, to model when necessary, to review constantly, and to expect coding to be an almost trivial endeavor.
My dream is for the new grad of the future, EE, CS or CE, to come out of school expecting businesses to employ some sort of disciplined development process. When they find that their company doesn't use firmware standards, inspections, and the like I hope they are horrified. and quit. Let's hope they demand real design, and they avoid plunging into coding too early. For though they may initially tilt at the windmills of inertia, in time these people will be the team leads and then management. Perhaps then the software crisis my head towards resolution.