A Call for a New Curriculum
A Call for a New Curriculum
Half or more of the firmware developers I meet have EE degrees. It's odd that these experts at transistor theory, electromagnetics, and IC design spend their career cranking C and C++ code.
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 firmware's complexity increases, it also becomes more like application code. Implementing drivers and ISRs will always require hardware insight, but that might be one percent 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 people contend that EEs are better problem-solvers than CS folks, thanks to their analytical nature that their 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 are the fundamentals of the language -- now write a program to do thus-and-so." Process is almost unheard of. Almost none of them 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 may head towards resolution.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at firstname.lastname@example.org. His website is www.ganssle.com.
This article started well by explaining fundamental differences between engineers and CS grads.
Then he continued on to explain some things I totally disagree with:
1.) People should write more code in school. Currently they are only writing enough to learn syntax. Assignments should be created to help students grow... for example one shot 2 week assignments are a waste of time ... unless there is a chance to take that work to another level.
2.) Coding = Experience. Methodolgy is only an ideal ... practice of this without any experience will only hurt you in the long run.
3.) Code Code Code ... Its the only way to learn anything that will be useful.
4.) Methodolgy is expensive. And many times taken way to far ... for the better part it is not economically feasible ... no one will buy your methodolgy.
My ideal grad is one that without any hesitation says "i can do this" ... does it quickly ... and screws up quickly ... then re does it if necessary ...
Just my rant ...
Why not grade the code students write based on real-world critera? Work could be judged on adherence to coding standards, quality of comments, clarity of form, use of descriptive names, and so on.
Here's another idea: Give students some of each other's code to debug and document, then grade them on the result. That should sort the sheep from the goats in short order!
Nothing I know would tame the cowboy coders more quickly than having to ride each other's horses, so to speak.
Bruce P. Holmen
I think college doesn't teach people to write programs - it merely teaches the syntax of the language being used. Sort of liking taking an English grammar course - then expecting the graduate to start writing Great American Novels.
Jack is absolutely right - its much more important to learn how to work within a team - how to organize a project and develop good problem solving skills. These skills are learned on the job - and since there is no way to know who does this well - the quality of learning (and teaching) is very poor.
I don't think the software "crisis" will ever disappear. As a 20+ year veteran, I can remember so many (too many) cures for the crisis. One reason that many EE's may be employed as firmware developers is that we hope that the skills used in designing circuitry will cross over into the software field. However, the current trend seems to be to make hardware development more like software development. Did I miss something?
The best part about software development is that the software is so easily changed. The worst part about software development is that the software is so easily changed. No I didn't accidently copy the two sentences - I think that most people in the software development business do not sit down and think about the task to be done - there is too much of a rush to jump in and code before fully understanding a problem. Communication is poor - most techies can't seem to put two coherent paragraphs together, let alone a good report. Yet much of our work consists of describing what we want to accomplish and how to get there - whether in a technical language, assembly instructions, etc.
This is what school should concentrate on - devloping a sloid technical knowledge base and teaching how to communicate.
Director, Product Development
So how does one of these infamous EEs without any software engineering training drag himself and his employer (which finds the idea of a written Requirement Specification novel!) into the 21st century while continuing to ship products and keep the mortgage paid?
There seem to be about half a dozen different, competing views of how S/W development should be done, most of which do not consider how you would migrate an existing organization to "the better way".
It would be nice to be sitting in a nicely fortified and landscaped mountain kingdom but many of us are stuck in the trenches up to our knees in mud.
JACK REPLIES: Understood... but do we dare abdicate our responsibility to bring some semblance of order to our work?
I agree that codeing needs to be downplayed and that process needs to be emphisised. Unfortunetly it requires a fairly large, and complicated, project to convince students of the this need. This sort of project rarely shows up for EE students. CS students will probably only have two or three classes, and unless the professor emphesises process, along with what ever their expertice is in, students will think they can hack out a program just like the little programes that tend to predominate most of their colledge experience. Process must be a part of every class, from the beginning, or students will not follow. I know this from experience.
University of Utah
As a whole I like this article. For me, I never attended post-secondary education (highschool) in favour of learning on my own. While doing this, I came up with a number of design methodologies that work very well for me, and a few other people I have helped out over the years. I believe these skills need to be learned early and most schools don't do that. If you can't plan your code from beginning to end, you have no way of knowing what you may need to take into acount that can affect the rest of the code. If someone is just coding blindly, there will inevitably be problems.
There was one aspect of your article I did not like very much however, "When they find that their company doesn't use firmware standards, inspections, and the like, I hope they are horrified -- and quit.", that just doesn't sit well with me. When I started with the company I'm with now, it was mainly the work of one guy who did whatever he pleased. Through perseverence I have managed to get certain changes implemented and we have come to many agreements regarding design and coding. I believe that instead of just running from a situation, take a stand and show people the "why's and how's" of proper design. If you can pull it off, you can come out of the deal looking like a real team player who's interested in productivity, a real plus with management let me tell you.
The last point is just my opinion however. I know some people just like to start coding and don't really want to get involved in policy making, and that's just fine too. To each their own!
Reliable Controls Corporation
No, it takes more than an idiot to "crank" code. At least, it takes more than an idiot to write good code.
However, any idiot can learn a flavor-of-the-week "process". Plus, the ability to focus on process rather than product is a developmental one and requires experience, as well as many years of first developing just product. You can not expect a 20-year-old student to care about CMM any more than you can expect a 12-year-old learning Logo to care about portability and robustness.
Colleges and universities can provide an introduction to software engineering. All of the undergraduate curriculum is essentially an introduction to everything. It is up to each company to further train their employees in the processes that they need to develop.
Your column sounds like more of the "You Train, We'll Hire" mentality that companies have towards universities. The reality is, and I hope it stays this way, "We Educate, You Train"
JACK REPLIES: I couldn't disagree more. To me, coding is relatively mechanical. Design is hard. Discipline is hard. Both of these require a philosophy of engineering that I'd hope college could encourage.
Please produce people who think deeply and understand the process of engineering. What we don't need are coding droids.
Grand Valley State University
I found myself unable to vote in your poll, since none of the three choices fit me and I'd wager that they don't fit a number of other embedded engineers who may have more typical educations than mine. I have a BA degree in math with a minor in comptuter science. Was this education "irrelevant to my job"? Absolutely not. I draw on the math frequently and although there's not much call for Fortran and Pascal these days, the programming principles that I learned are still relevant.
Did I "learn to crank code?". Not really. Yes, I wrote programs. Yes, they were the focus of my assignments, but asking someone to get a computer science degree without writing code, is like asking them to get a creative writing degree without writing anything. The code I wrote was the first step in learning my current occupation. It is the first layer of tools in my toolbox. The other tools that I learned in college were structured programming, basic algorithms and how to evaluate good ones, representation of data structures, etc. These may not be "software engineering" but they are certainly necessary for a software engineer. In four years of undergraduate work, I went from never having sat in front of a computer to a hirable competent coder. Those four years were not nearly enough time to make me a software engineer. That training came daily, over the rest of my career and will continue until I retire.
I agree that colleges should not emphasize "cranking out code", but coding is a fundamental tool that must be learned. So is planning, methodology, and teamwork, but the actual experience of this in the college environment will be forced to be scaled down to fit within the confines of a single class, or -- if you're lucky -- a senior project or other series of classes. Undergraduate institutions can teach why engineering methodologies are useful and should be used, but only on- the-job experience can teach us true engineering.
Principal Software Engineer
Clarity Visual Systems, Inc