Electrical Engineers versus Computer Scientists
Looking back at my various blog postings, I've noticed that although I may be controversial on technical topics, I haven't to date written anything that is controversial on a, shall I say, human side. Well no more Mr. Nice Guy, since today I intend to wade in on the topic of whether Embedded Systems should be programmed by Electrical Engineers or Computer Scientists. Regular readers will know I'm an EE (actually my degree is in EE & ME - but that's another story) and so you won't be surprised to hear that my usual preference is for Electrical Engineers. Although I am a (very) opinionated person, I'd like to think that most of my opinions have some basis in reality, and so here's my opinion and its supporting observations...
The more embedded a product is, the better off you are with an EE, the less embedded it is, the better off you are with a CS.
So what's the basis for this overblown, sweeping generalization and what exactly do I mean by 'more embedded'?
Well, I consider a product to be highly embedded if it meets one or more of the following criteria:
- It has no or very simple user interfaces.
- It performs a lot of hardware type functions in software. For example a DSP that performs a lot of signal processing is essentially doing in software what was once done in hardware.
- It contains a lot of complicated hardware that needs extensive configuration and software support (For example a PowerQUICC processor).
By contrast, I consider a product to be lightly embedded if it meets either of the following criteria:
- It has a sophisticated user interface (especially if the interface is web based)
- It is database centric.
Evidently there exists products that meet the criteria for both sides of the dichotomy. For example, my new flat screen TV has a very sophisticated user interface, but I'm sure it does an extensive amount of signal processing.
If you accept this dichotomy, then it is evident that folks working on highly embedded systems really need to understand the hardware (since that's what the product is about) whereas those working on lightly embedded systems need a good understanding of how to build large software systems. Having said this, my experience is that whereas EE's (OK some EE's) are able to quickly learn the principles of building large software systems, I've never yet met a CS major that had anything beyond a casual understanding of what's really happening at the hardware level. I've seen this lack of knowledge (interest?) manifest itself in many ways. Examples include:
- Not knowing / understanding the Nyquist Sampling theorem
- Failure to realize that EEPROM / Flash have extraordinarily long write times
- Not realizing that sampling jitter can destroy the performance of a digital filter
What about the other way? Have I seen EE's write 1000 line functions, and be completely clueless about principles such as data encapsulation? Absolutely! However, I have also seen EE's successfully craft very large systems. As a result I've come to two basic observations:
- A deeply embedded system written entirely by a CS major will have major problems.
- A lightly embedded system written entirely by an EE major may have major problems.
On this basis, I prefer (slightly) to have EE's work on embedded systems.
It doesn't take a rocket scientist to conclude that perhaps the best approach is to have a team where the EE's handle the hardware centric stuff and the CS's handle the computer centric stuff. Indeed, this is the approach I see taken in most organizations.
As a final thought, although it is common to find EE majors that have gone back to college to get a Masters in Computer Science, I haven't yet met a CS major that has gone back to college to get a Masters in Electrical Engineering.
posted by Nigel Jones @ 3:26 PM
17 comments
17 Comments:
The real problem is that neither an EE nor a CS degree alone properly prepares a person to work in the challenging field of embedded software development.
You have laid out some of the hardware and "big software" technical challenges. But there are additional issues lying between your "lightly" and "deeply embedded" pieces.
Neither an EE nor a CS degree prepares a person for these challenges, which include data volatility, race conditions, non-reentrant functions, and making good decisions about whether and how to use a preemptive RTOS to meet deadlines.
Even a CE degree doesn't help there. In the right work environment, either a CS or an EE person can learn to tackle these issues. But in the wrong environment there is no feedback other than unresolved "glitches" in the products they create.
The project disasters I have been unfortunate to pick up have had one thing in common. They have been written (hacked) and managed by non software engineers.
Although I accept that people interested in GUI's and databases are unlikely to be interested in low level programming. There are degrees in Micro-computing, maybe this provides a more appropriate mix of basic skills?
***Disclaimer*** MCSE Here :)
I would agree completely except for your overly generic description of CS.
I believe you truly feel that EE's are better suited for Engineering in general, lets ignore the fact that most deaths from embedded systems software have occurred at the coding fingers of EE's that decided to write code because they figured out how to write a procedural program. The only problem I have seen with EE's code is that there appears to be a lack of system level thought. Sure, they get the algorithm, Wikipedia is full of them, but balancing system load, multiprocessor embedded, and M2M data requires coding and system discipline that may be just beyond the generic EE program offerings.
BTW When an EE gets the MCS it is to grow in corporate eng. and MS degrees are desired. All the Electrical Engineering you describe in your post is undergrad EE. I don't know why anyone without an undergrad in EE would be interested in a MSEE.
Best option would be dual degree EE/CS, but then Computer Engineering fits most of that bill now too.
I guess it really comes down to the individual, not the degree. But you definitely acquire a deeper understanding at the graduate level, as opposed to Undergrad.
Lastly, lets use some better terminology, Lets call it soft real-time systems for non critical systems, displays, buttons, etc. Lets call it hard real-time systems for TV Picture sync, sound, etc.
I would argue that a hard real-time system written entirely by a EE will fail, and will have major problems if they are not 100% familiar with the entire system.
I would argue that a soft real-time system written entirely by a CS will fail, and have major problems if they are not familiar with signal conditioning, arithmetic mean calculations, timing problems, hardware interface, the list goes on, and hopefully my point is made.
Who would I want to work with on my next hard real-time project. Computer Engineering, or EE working on CSE.
I'll take the bait and be the anomaly. I'm a BSCS and have considered getting a BSEE except that the career prospects look better for an MSCS than MSEE here in the US. Most of my work has been a mix of EE/CS work, rather than one or the other.
I am an EE with many years of experience doing embedded hardware and firmware design. Most EE's I've met aren't up to the task of writing good embedded firmware (or software if you really prefer to bend the term), generally because they don't get that kind of training. But I've yet to meet even one CS that's up to the task. CS folks seem fundamentally unable to come to terms with the concept of resource constraints (time, memory, power, performance, etc). Given a good CS, he knows what to do to improve the performance of a PC application, but that isn't even close to being the right knowledge for embedded firmware design. My experience says I need to provide 5 or 10 times the hardware resources if the firmware's going to be done by a CS and even then I'm going to regret letting the CS at it. Designing for correctness also seems to be a real problem with CS folks. I don't know if it's the PC world that's taught them that it's okay to iterate to correctness or what, but the sorts of embedded system design I'm involved in simply cannot tolerate updating in-field systems a dozen times before they appear to be reliable. I no longer accept CS folks on embedded projects at all. It's still tough to find an EE who's good enough, but I do find them.
The absolute worst efforts I've seen are from physicists and physics engineers, but that's a whole other discussion :-o
No mention of CpEs?
I think it really comes down to the individual developer. Some CS majors make terrible programmers and some EE majors are great.
I started college in an EE program but finished with a CIS degree.
I have programmed for embedded systems(C/UNIX) and for large scale databases(Object-Oriented,C++/Java).
The main prerequisite is your ability to understand the key concepts involved.
I'm not sure how common it is, but some universities offer Computer Engineering degrees. At UC Santa Cruz as a CE student I took software classes like operating systems, networking, and realtime embedded programming. I also took classes in signal processing, mircocontroller design, high speed digital design, and verilog.
For someone interested in embedded systems this type of program is what you are looking for.
Of course, if you're a double major (or CS with an EE minor), this doesn't apply ;)
Or you work in a time that has a good CS and a good EE working together...
But ultimately, it boils down to hiring people who are good at doing what needs to be done. It's not a function of the degree, it's a function of the selection process.
And by "work in a time", I mean you "work in a team". Sheesh.
I guess there are some things a CS major just can't do. Deep embedded programming is one of them.
Myself I have an EE degree. However I stay away from embedded systems because I love the software side.
I'm going to school right now to learn some CS. Maybe I will encourage my peers to go get an MSEE.
It's an interesting perspective, especially in light of your other blog post about using truth tables, a database, Perl, and Espresso create C code that most CS folks would consider an ugly abomination and would immediately want to refactor for the next poor sap who comes along and has to try to parse a 9-line test with something above 40 or 50 separate (and repeated) logic operators.
Hi Anonymous: I'm not sure what your point is regarding my posting on Espresso etc. If you'd expand upon it a bit I'd be happy to reply. Thanks.
I guess none of you should ever fly.
Because the majority of code in the embedded systems that are part of the flight controls and engine controls in the majority of aircraft today are written by people with CS degrees (first hand knowledge).
I'm a CS major who's done a lot of embedded programming, and I feel very insulted. The key to any sort of programming is being a smart person. Forget degrees. Degrees are meaningless. I've learned 10 times as much with real hands-on work than I ever learned while studying for that fancy piece of paper.
It's up to each person. A person has to be able to adapt to new environments, organize properly, and most importantly have an appreciation for subtle details. I never needed an understanding of current or voltage or how to design a CPU in order to understand how to avoid and fix race conditions, solve CPU cache coherency problems, and avoid stepping on memory I didn't allocate, and I did it all while writing modular and maintainable code.
Your technical posts are useful and insightful and I thank you for that. This post however, is not of the same stock.
A piece of paper is not a substitute for a brain. Learning is not simply an event hosted in a classroom. A monkey who cannot learn, or who doesn't want to learn what he needs to know to solve the problem at hand, is of no use, regardless of the problem or where you found him.
I don't understand why a person's skills are based solely on the degree they got in college. Quite honestly I'm used to these types of generalizations coming from EE undergrads. Whether you go for an EE or CS in college, both degrees teach the critical thinking skills that allow either a EE or CS to do work on both sides of the fence in the real world.
There is nothing stopping a CS from learning the hardware side of an embedded systems project. That is the biggest issue I have with this post. And I see this alot from EE undergrads; that mentality that EE cannot be learned unless you get a degree in it. Having been through both programs, I believe anyone with enough time can learn any of this stuff on their own. Therefore, this entire CS vs EE topic is null and void.
Post a Comment
<< Home