Common Misconceptions About Software Engineering | News | Communications of the ACM
October 15, 2010 at 11:01 am 1 comment
Leigh Ann Sudol’s and Ciera Jaspan’s paper from ICER 2010 (that I blogged about) got a special write-up on the CACM website, and included a quote from Yours Truly.
Software engineering is increasingly recognized as a separate discipline from computer science, but it is often learned on the job. Universities are creating programs to prepare students for jobs developing large-scale software, but many students have misconceptions that hinder their transition to the workplace.
To systematically probe what software engineering undergraduates think will matter in their jobs, computer science graduate students Leigh Ann Sudol and Ciera Jaspan surveyed undergraduates at Carnegie Mellon University. Their results, “Analyzing the Strength of Undergraduate Misconceptions About Software Engineering,” explore both the students’ misconceptions and how their views evolve as they gain experience. Their paper was presented at the 2010 International Workshop on Computing Education Research .
via Common Misconceptions About Software Engineering | News | Communications of the ACM.
Entry filed under: Uncategorized. Tags: computing education research, ICER, software engineering.
Computing Ed Research - Guzdial's Take 
1.
Alan Kay | October 16, 2010 at 8:42 am
There are several questions whose answers would provide further illumination.
One is what percentage of students can define “computer science” without creating an engineering definition? (Informally a few years ago I had a chance to ask mostly grad students to define CS and didn’t get even one non-engineering answer.)
More interesting would be to hear their definition of “engineering” and “software engineering”. I should have tried to elicit this also, but didn’t.
A bigger and also more subtle issue has to do with cases when the first order theory and the second order theory contradictory and both right!
For example, it has long been a first order theory that you should use existing tools and code as much as possible and avoid the black hole of making your own tools, languages, operating systems, even hardware. This is generally true.
But so is the second order theory. If the project is difficult and you have the chops to make the special tools, languages, operating systems, even hardware, then you should absolutely do it. This is what was done at Xerox PARC and it was the only way that very difficult set of projects could get done an working in just a few years.
I think one could make a very strong argument that one whole area of “things gone wrong” in big software projects comes from poor architectures, and that these stem from a combination of the bad tools not being good at making a good architecture, and from bad tools making it really difficult to even thing good architectural thoughts. (The latter might be the dominant factor)
Cheers,
Alan