software and higher education

My copy of Communications of the ACM (my nerdy fun reading) arrived this week and on the inside of the back cover was an article by John Knight (one of my former professors) and Nancy Leveson on Software and Higher Education (article in HTML, article in PDF). Knight and Leveson claim that the fundamental reason why software projects go awry so often is because those making technical decisions are not well-equipped to do so -- and the blame for this is directed at deficiencies in computer science and computer engineering degree programs.

To briefly summarize their points, they find in CS and CE degree programs:

• Emphasis on fads and not principles. That is, a graduate might know a lot about C++ or Java idiosyncrasies, but know little or nothing about principles of software development or fundamental techniques for specifying requirements or testing, which is of course what software engineers do at work day in and day out.


• Computers are viewed in isolation. Computers rarely stand alone, but rather as a part of a larger system. While students are working on programs that run purely on PCs or on the Web, most software engineering work is done in the context of a larger system. For instance, software that controls assembly line machinery, software that runs in the cockpit of an airplane, or increasingly software that is embedded in personal devices (digital camera, mobile phone, etc...).


• Design topics are taught from a narrow perspective. In many programs, object-oriented design is the only design philosophy presented and treatment rarely goes beyond covering the existence of objects and classes. There are other approaches, old and new, that deserve treatment because object-oriented design does not solve every problem gracefully and besides, it's good to help students realize that there is life beyond OO and they could be the one to come up with it :)


• Graduates don't know what their limits are. They should have an understanding of what well-known techniques they can choose to solve a problem just as much as an understanding of where limitations are so they can find more help or prevent a project from going south by trying to achieve the improbable or impossible.

Based on my experiences in industry, I tend to agree with Knight and Leveson's point of view, although I know there's a chance I might be biased because I've taken Knight's class, Advanced Software Development Methods, which I found demanding, intellectually rewarding, interesting, and definitely most applicable to what I do today. If anything, I think Knight and Leveson are spot on in their article, and the other deficiency I would add to their list is that many graduates are not aware of the resources they have available to them in their field. More times than not, Google search tends to be the one (and only one) source people go to. Not that searching on the Web for answers is a bad thing, but in my experience, a lot of the "engineering" and even programming advice I've come across on websites and forums are garbage, especially when one starts taking technical advice out of the context. Yes, it's a strong statement, but it's true. So if graduates aren't aware of good engineering techniques and they aren't aware of resources that are reliable (or worse, aren't aware of how to evaluate sources of technical information), seeking solutions and answers on the Web will lead to inevitable follies and failures. (Keep in mind, the cost and accessibility of good information and resources is an issue for another day.)

Although I firmly believe that good software engineering needs to be taught, there are some (not the authors, but others in the software community) who engage in a pointless debate between the definition of computer science (some say CS is theory) and software engineering (some say SE is application). In my opinion, being a good software engineer requires an in-depth understanding of computer science and being a productive computer scientist requires an in-depth understanding of software engineering techniques. So hashing a line between them only creates a false boundary where people can make excuses to stop learning. However, I agree with Knight and Leveson in saying that degree programs should inform their students what their goals are: to produce a graduate who is ready for a career in research, or to produce a graduate who prepared to work in industry. At least advise students on how to steer their learning emphases. It would be ideal if a student in a program could learn everything of course, but the fact of the matter is, there's not enough time in four years. Four years is just a kick start for an inevitable lifetime of learning :)