I have a BS in Computer Science from Carnegie Mellon University, and there we had to do (almost) exactly this in Software Engineering II. A random volunteer from the admissions department came in to describe the software she uses for admissions, we had a full class time to interview her and attempt to get as accurate an idea of the software as possible (without ever seeing it or using it). From that, groups wrote up software specifications, and traded them amongst each other, at which point the next step was to (partially) implement it in code. Needless to say, the professor had to provide us with a small amount of additional details about the software so that we could even attempt to come up with a spec (imagine trying to build M$ Excel by having someone who inputs data all day explain to you what it does), and in the end the results were hit or miss. It was however a great exercise and provided a lot of insight into learning how to interact with the end user and meet their expectations when developing code.

As to the OP (on version control), when I took an OS course, starting from the first group assignment (replacement syscalls for a generic kernel) we were instructed to use PRCS for version control. A number of students didn't know how to use such a thing, but an FAQ was provided and the professor and TAs were ready to explain and help set up repositories for the students as needed. That's likely the best way to do something like this: require it from the first project, provide a basic guide on setting up a whatever VCS you would prefer your class to use, field questions from students that have problems.

And on open source, in Software Engineering I, the final project for students in the class was to choose an open source project and contribute to it. We had to document the full process, including the methods of interaction with regular contributors, how you decided what to contribute, what you actually did, and the result. One group of two students chose Pidgin and were able to resolve an issue from a bug tracker report. In the end it was only 2 lines of code, but what was important was the documentation (and presentation to the class) of the rest of the interaction. I chose a project I had already been a contributor to (informally) in the past, KOS: an open OS for the Sega Dreamcast, and wrote a driver for the memory card speaker.

Both of these software engineering courses were simply electives that fulfilled a breadth requirement for the CS degree, but were not necessarily part of a larger Software Engineering track. I can't imagine a CS degree program though that does not teach any programming, as all CS students at CMU were required to take at least one course in C on Unix, two courses on Java, and a 'systems' course (which involved learning software-hardware interaction: writing a malloc replacement, a working web proxy, optimizing a matrix multiplication function, and defusing a blackbox 'bomb' program via disassembly [program would say 'Answer to #1 is?' and you had to disassemble to figure it out]).

Perhaps all that could be boiled down to explaining why CMU is the top CS school in the country...

While it can make code harder to read, it can also help show certain specifics and at least with my experience with gcc will produce faster code (due to better register usage, and superscalar optimization) in many applications.

Take the following simple example:

a = x(); a *= y(); a += z(); vs a = (x()*y())+z();

This may look trivial, but it can make a difference to someone showing up later, as well as to the compiler now. Of course, depending on x,y,z the two may give different results, but I write assuming that both demonstrate the 'correct' outcome. The two show different rules as to the order in which operations must be applied. The second uses language much better suited to explaining a relative order which allows the compiler to decide what is best depending on what resources are free, not only that, but it will show whoever is reading it more explicitly the required order.

If I were to come along the first one at a later time, it would take some digging to ensure that x,y, and z are not dependent on one another and the order they run in does not matter to their results. With the second, it's clear from the start.

This is in many ways an extension of an adage I was barraged with in many high-level-complexity, low-level-code classes "NO MAGIC NUMBERS!". The idea was to use defines or variables instead of fixed numbers whenever possible. It worked to make code more readable, and more flexible with minimal extra effort.

It seems as if they are trying to liken this to the opposition of some of the deaf community to cochlear implants. A much better example would simply be poor eyesight. It's not as though colorblind people are typically unable to function easily in a world designed for the full spectrum'd (?) to the point where they form a communal bond.

An interesting reversal to 'cheating is due to teacher's laziness'. At Carnegie Mellon University all the CS courses are original to the school (although reused year to year), The problem is many schools (Stanford included) will copy the same course. This makes it easy for any student to find the page of a course at another school where they didn't take down old material and snag answers from it. One of my professors sent half of the first class lecture on what he considered cheating and what wouldn't be tolerated, including searching on google for help. On the day the first assignment was due, many were snickering at those who spent a day working out the answers (great theoretical ideas in computer sciece) and a list of names was put up on a big projector labelled 'cheaters'. The professor had created a site a few weeks prior with answers to one of the questions and guaranteed it would show up as top google result. He collected IPs, which if you used a school internet connection are easily tracable, even for students. All those students were given no credit and warned against cheating in the future.