Excellent discussion, thanks!  When I was at UCLA a billion years ago 
the graduate students who taught the second programming class tried 
to teach us some design aspects as well.  For instance they 
encouraged us to find common-subunits possible in programs (ie, Kent 
Beck's "say it only once").  I always thought they did a good job.  
Clearly what Mark is doing goes much farther, and sounds great.  

At the end of the course, Mark, have the students internalized these 
design ideas?  Do follow-on courses revisit these themes and take 
them farther, for instance, talking about design patterns?

By the way, I have the White book and found it extremely useful.

Best,

Mike

On Tuesday 10 September 2002 06:55 am, Mark Guzdial wrote:
> On Monday, September 9, 2002, at 02:38  PM, Göran Hultgren wrote:
> > Ok, let me be a bit frank.
> >
> > PWS might be simpler in terms of LOC but the design gives me the
> > creeps. What is
> > an instance of the class "PWS"? A server? Or a request? And if it
> > is a request
> > (which it is) why is the class called PWS and why does it have
> > class methods as
> > if it was a server?
> >
> > In short - I find it very poor "OO design" having the class
> > effectively being
> > the server singleton and instances of itself represent requests
> > to it.
> >
> > I know that PWS was whipped together very quickly (IIRC) and that
> > is fine by me
> > but... Ok, I can't refrain from saying this - *personally* I
> > would not use this
> > code in a course called "Objects and design".
>
> I understand your complaints, but my decision is based on
> pedagogical strategy.
>
> As a graduate student, I worked with Elliot Soloway, who's thought
> a lot about how we teach computer science.  One of his complaints
> is that we rarely teach design -- most textbooks show students
> completed works of lovely design and announce "Ta-dah!" without a
> word of how we got there, nor why it's a good design.  One of my
> goals with the White Book was to directly address this criticism:
> - The White book builds things over-and-over.  Joe the Box gets
> done twice.  The Clock UI gets redone FIVE times.
> - I explicitly point out both good and bad design.  Your complaints
> about PWS are made very explicitly in the Case Study chapter.
>
> One of Elliot's papers is titled "'But my program runs!': Discourse
> rules for programmers"  The common complaint from students who get
> points taken off for bad designs is, "But it works! Why should I
> get points taken off?"  As novice programmers, it's very hard to
> get students to recognize bad design -- they simply haven't had
> enough experience to be able to understand the alternatives, that
> there is more than one way to do anything.  My class is for
> Sophomores -- they're ready to move past that point, in my
> estimation.  So I very explicitly have them use things with "bad"
> design -- we critique it, we point out that it works but that isn't
> enough, and we have them use and even extend it so that they get a
> sense of what it's like to live with not-quite-100% designs.
>
> In my opinion, school should not be a museum of lovely works that
> one admires but doesn't touch.  Learning occurs much better in the
> sandbox or at the workbench, where you learn to deal with things
> that aren't 100% and you learn to recognize the good and the bad. 
> To teach design, I'd much rather have students use something whose
> faults we can carefully analyze, than simply assign use of
> something terrific that goes without comment (or that we can only
> say good things about).
>
> Mark
>
> __________
> Mark Guzdial : Georgia Tech : College of Computing
> Atlanta, GA 30332-0280
> Associate Professor, Learning Sciences & Technologies
> Collaborative Software Lab, http://coweb.cc.gatech.edu/csl
> http://www.cc.gatech.edu/~mark.guzdial/