Developing large scale software in industry can be an extremely frustrating experience. Some of what is to be learned from such a project has nothing to do with programming. One learns the politics of group dynamics, to deal with documentation and support code, the problems with integration, and the importance of stability and bug-free code. Much time is spent learning about these issues and often the focus can be shifted away from design and coding. Large scale projects such as the lab described teach students how difficult software-engineering is by showing the negative aspects of it.
Although a project such as "The Nightmare on Westwood Avenue" can be a tremendous learning exploration, I do not believe it is appropriate for new programmers. There are many levels of frustration for a programmer. As I see it, the difficulties that arise in programming are as such:
One extreme fault in the write-up created is that there is no understanding of how far along the students are in their programming knowledge. I should like to assume that students mentionned in this article had extensive background. Such a large scale project can be a very viable system for students once they are comfortable with their own skills. On the contrary, I do not believe that it is a viable system for new programmers. Beginning programmers are dealing with other issues such as how to think for a computer and how to deal with syntax. Dealing with larger issues is virtually impossible.
Although the proposed project is far above the abilities of the new programmer, I fear that even a smaller scale group project would also be challenging. At an introductory level, understanding one's own code is difficult; understanding another's code is tremendously frustrating (especially if their code has errors).
Large scale software engineering is an important skill for every computer scientist who intends to work in industry. Two major methods are used to teach this- group interaction with industry or group interaction in-house. The latter focuses tremendously on developing group dynamics and programming skills whereas the former also deals with extraneous issues (including multi-platform issues and outside specifications). Although this is important for industry, students often do not have the time to go this in-depth and learn what else is necessary to succeed as a computer scientist.
For starters, I think it is blatantly obvious that your response shows a bias against industry related work. Due to this bias your response is extremely one-sided. It might be a good excercise for all of us to try and throw our own personal biases out while reading and responding to these articles. Having done this we become free to look at and understand new ideas. Even if these new ideas look "faulty" at first blush they can have an extremely positive impact on us by jarring our mind in a way that we have guarded it against for so long.
Having said that I agree, as I did with Chotin's response, that such tactics would most likely not be very fruitful with beginning students. However, I disagree that looking at other people's code, when a beginning programmer, is always frustrating. When I was learning Pascal, back in High School, sometimes the only way I could learn was by havbing my friend show me his code and answer questions about it.