In addition to the above, it seems as if using 3rd party "purchased or obtained technology" is comparable to using sketchy support code -- except for the fact that the authors of the code aren't involved in the project. Students are going to find out ver y soon that they are going to have to adapt their products to an outside standard. Again, students in an intro course, especially those that have never programmed before, are going to find another headache has been added to the stack. CS15 is tough enou gh relying on TA's with multiple years of experience for guidance; working in a blind leading the blind situation can't be much better.
The choice to not distribute the program to the "host university" during the first year may have been a bad one. If you're going to stay focused on practicality and real-world experience, you'd want to avoid the homogeneous user group that the article ke eps referring to. In 15, some students would decide that their program was "good enough" to fill the requirements -- probably not the case with an oustide test group.
I believe that the results of the experiment clearly support a major change in the structure of the development process. Unacceptable design and "extremely flawed" implementations are not time-efficient. When teaching introductory courses where habits a re formed, students should be taught to do something right or not to do it at all. However, part of this approach could be adapted to CS15, maybe a modular design philosophy (not sure if this is the correct terminology). Perhaps have each program be a b uilding block to the final project, or second to last assignment. That way, the students would have in effect created the magic, and seen (somewhat) multiple facets of software development. However, I feel this should not be done in a group, but rather independently.
I agree with this view about building programs from the ground up. However I disagree on your view about giving the program to the host university. I think that in this case the projects being failures was the reason why there was no distribution, as opposed to telling the students that this year they would not be given out. In a normal software engineering process, the client would beta-test the software before giving final approval, and I assume that this class would have done the same.
Saul's Response
Teaching it right or not teaching it at all. For design,that is great, but there are many sides to "correct design". However, I agree with you. Letting people with no experience fall flat on their face is not a good way to instruct.