How to teach design (was Re: Squeak book !)

Roger Vossler squeak-dev at lists.squeakfoundation.org
Wed Sep 11 01:05:40 UTC 2002


Hi Gang,

OK, let me be a bit more frank.

If we do an autopsy on Squeal and lay it out on the dissecting table=20
for all to
see, how much of it qualifies as "good design" and how much of it as=20
"bad
design"? I keep hearing people talk about good design, but I have read=20=

very
few good books on bad design(s) with examples. :-) I keep rereading the
Mythical Man Month as a yardstick to measure how little progress the
profession has made.

Cheers, Roger.....

PS: But, it works.....

On Tuesday, Sep 10, 2002, at 10:11 America/Denver, Michael Fremont=20
wrote:

> 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=F6ran 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/
>
>
>




More information about the Squeak-dev mailing list