The August 2014 issue of Communications of the ACM contains an excellent article (paywalled to ACM members) titled “Undergraduate Software Engineering” by M. Lutz, J. Naveda, and J. Vallino. The authors complain that computer science (CS) curricula don’t teach the important concepts behind software engineering. Graduates learn about coding, compiler design, operating systems, and similar subjects but get no exposure to version control, working in teams, and actual problem solving.
While the skills acquired in CS are useful, they are far from complete, and miss the most important parts of real-world work. In fact, the very name ‘computer science’ is exactly wrong for nearly all graduates of such programs. Few will go into the science of computation; most will work as engineers – people who build things. The casual person on the street probably doesn’t understand the difference between science and engineering, but we practitioners know they are worlds apart.
The article describes a BS in Software Engineering program at Rochester Institute of Technology (RIT) that is separate from the school’s CS program. It stresses design and modeling instead of coding and programming. Design is the hard part of our jobs; coding is just the implementation of a design. Other than software I can think of no branch of engineering where the primary focus is on implementation. Civil engineers don’t pour concrete, EEs struggle to get their schematics correct before building boards, nuclear engineers design a containment vessel before welding starts.
RIT’s BSSE courses cover material like concurrency, not from the OS’s perspective but from building applications that must behave well in the difficult framework of multitasking and multicore systems.
The senior capstone project isn’t one semester, as is the case in most programs. It’s a real project with industrial customers, and spans two semesters. I taught a capstone project for seniors and grad students at the University of MD some years ago. While it was great fun and challenging for the students, the projects were really toys. At RIT these projects are done by teams of 4-7 students. In fact, all of the work from matriculation to graduation is done by teams, since in the real world it’s unusual to work alone.
Regular readers know I’m adamant about metrics, as numbers are what separates engineering from art. In the RIT program students constantly collect metrics, for instance, estimation numbers, to see how their predictions match the actual results.
The school’s web site shows the labs , including one devoted to embedded and real-time systems. The picture is small and hard to make out, but it appears to be completely lacking in test equipment like scopes. That’s a real shame. And, strangely, the BSSE program is not in the college of engineering, but is a part of the college of computing and information sciences. As Ronald Reagan might have said, “There you go again, conflating science and engineering.”
The curriculum flowchart is too large to reproduce but you can view it here . It seems to be a five year program which includes a full year of mandatory co-op experience. A FAQ says students typically make $20/hr during their year in industry.
At $47k/year RIT is not an inexpensive school, so this program is available for only the affluent or those willing to be saddled with crippling debt.
RIT claims to be the first to offer a BSSE. Today other schools have similar programs.
According to the Computing Research Association (CRA) about 64k students were enrolled in CS in the USA in 2013 (though they only count PhD-granting schools). That’s part of an upward trend starting in 2009, but is still 25% off the highs at the turn of the century. I bet the majority of those students would be better served by a BSSE program.
I’ve been advising prospective CS students to get a BSCE or BSSE. For the youngster with an interest in computing, what program do you recommend? Do you think ‘BSSE’ would pass the acronym filter so many large – and stupid – companies feed resumes through?
Jack G. Ganssle is a lecturer and consultant on embedded developmentissues. He conducts seminars on embedded systems and helps companieswith their embedded challenges, and works as an expert witness onembedded issues. Contact him at . His website is.