Oftentimes you might hear that people want to “freeze” requirements... You can't freeze requirements any more than you can freeze markets, competition, learning, evolution, or growth.  And even if you tried, you'd almost certainly freeze the wrong ones.

If all you do is take [your customer's]... initial requirements and implement them, you will certainly not be anywhere close to satisfying their requirements by the time of delivery -- the requirements will have changed.  You're exposing yourself to one of the biggest risks in software development:  you've produced what they asked for, not what they've come to want.  The result?  Surprise, shock, and disappointment instead of satisfaction.

2) Computer Science vs. Software Engineering

As I sorted through all of the calendars to piece together their programs and requirements, I noticed a curious pattern where some schools made a distinction between a degree in computer science with no specialization and one that focuses on software engineering.  The difference between the two fell squarely on whether any "best practices" courses were required, and even then the requirements for "software engineers" varied wildly from one best practice course to four!

This struck me as quite short-sighted:  In effect, it was entirely possible to get a graduate who could develop AI systems, write a compiler and analyze complex algorithms yet be completely dysfunctional in a software development team - all due to whether they took "Computer Science" or "Software Engineering".

This distinction is damaging, as it leads to some misconceptions about how software is developed, ie. that it is possible to "engineer" software as much as it is any physical object or machine. In 2005 I wrote about this disconnect under a post called That Damned Construction Analogy.  At the time, I referenced Martin Fowler's essay, The New Methodology where he states:

In software all the effort is design, and thus requires creative and talented people.  Creative processes are not easily planned, and so predictability may well be an impossible target.

In my opinion, when it comes to best practices there should be no distinction between "Computer Science" and "Software Engineering";  in fact, I'd go a step further and remove the distinction entirely as the notion of "engineering" software has very little to do, as Fowler observes, with how software is actually constructed.

3)  Those that do teach best practices, do it well

Overall, the departments that have gone out of their way to create courses that focus exclusively on a particular best practice or basket of practices appear to do it really well.  From content to labs to textbooks, it's a course worth taking - and unfortunately, isn't usually a required one.

Some examples include:

McMaster's SFWR ENG 3S03 Software Testing and Management;

Ryerson's CPS 845 - ExtremeProgramming and Agile Processes;

Queen's CISC 327 - Software Quality Assurance;

University of Toronto's CSC 207H1 Software Design and CSC 301H1 Introduction to Software Engineering;

York University's CSE 3311 Software Design and CSE 4313 Software Engineering Testing.

There are even more and better examples from other schools in Canada that I'll review in when I release the results of my expanded analysis next week.

4)  Most online course calendars are abysmal

In the interests of "dogfooding", I think a lot of schools would benefit from having their students evaluate their department's website and building a new one.  In almost every instance they are extremely frustrating and laborious to use:  A perfect example of what "software engineering" is doing to the industry!

A final thanks:

I see that Mike Gunderloy published a link to my post on his blog, Larkware.com - and that's put it in front of a good number of eyes.  Thanks for that, Mike!

Also, thanks to all who have contacted me about the article - it's great to get feedback on it and hear other opinions and observations.

Next Week:  The results from my Cross-Canada "Who's Teaching Best Practices?" CompSci School Review