Friday, October 14, 2005
Full throttle
Once in a while I scrap the exercises for my design courses and create new ones from scratch. It's not just to avoid boredom :-). It's to make the course itself more realistic: I'll have to confront questions I've never heard, discuss solutions I've never seen, make mistakes I never made :-), and that's closer to the real life of a software designer than going over a problem you know from each and every angle. I often encourage people to bring their own problems (for the same reasons) but I still come with a set of exercises, selected for their educational power.
I usually work out a reasonable solution - is doesn't have to be perfect: it has to be sensible, and to provide some room for discussion and for improvements. Designers (or future designers) need an highly developed critical sense.
Each and every choice has some good and some bad consequences: we must be aware of both, and choose the best trade/off between alternative designs. Of course, this is true in most areas of life as well. Nothing is just good. Especially in high quantity.
While sketching a solution to a new exercise for my design patterns course, or more exactly while thinking about the downside of a choice, I got one of those totally unrelated thoughts. Or maybe not so unrelated :-). It was about something I read time ago in "Extreme Programming Explained - Embrace Change" from Kent Beck: "When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible". So flawless? Full throttle, and no downside? How come I can't believe it? :-))
I usually work out a reasonable solution - is doesn't have to be perfect: it has to be sensible, and to provide some room for discussion and for improvements. Designers (or future designers) need an highly developed critical sense.
Each and every choice has some good and some bad consequences: we must be aware of both, and choose the best trade/off between alternative designs. Of course, this is true in most areas of life as well. Nothing is just good. Especially in high quantity.
While sketching a solution to a new exercise for my design patterns course, or more exactly while thinking about the downside of a choice, I got one of those totally unrelated thoughts. Or maybe not so unrelated :-). It was about something I read time ago in "Extreme Programming Explained - Embrace Change" from Kent Beck: "When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible". So flawless? Full throttle, and no downside? How come I can't believe it? :-))
Comments:
<< Home
Ciao Carlo,
mi sono trovato anch'io nella necessita' di fare degli esempi significativi per un corso di UML che dovrei tenere per i miei colleghi.
Ho scelto il classico (e noioso) esempio del Distributore Automatico. L'indubbio vantaggio, rispetto ad un esempio correlato al dominio dell'azienda (teleco), e' che tutti sanno di cosa si tratta.
Ho quindi riealizzato dei diagrammi per l'analisi dei requisiti (Use Case). Un diagramma per la domain analysis (Class Diagram) e uno State Diagram.
Per adesso manca completamente il detailed design perche' lo scopo principale e' quello di descrivere la domain analysis in UML ai colleghi del dipartimento di Mosca. Per vari motivi (principalmente legati allo schedule molto aggressivo) i russi non fanno nessun tipo di domain analysis. E adesso si stanno scontrando con l'estrema complessita' del sistema di cui non esiste una visione consolidata (appunto una domain analysis).
Mi chiedevo se questo esempio potesse essere usato come punto di partenza, e poi migliorato da te e dai partecipanti al blog, per poi riusarlo in tutti quei contesti dove e' necessario avere un esempio completo di design in UML (e.g. UML 2 Manuale di Stile).
bye
john boydon
mi sono trovato anch'io nella necessita' di fare degli esempi significativi per un corso di UML che dovrei tenere per i miei colleghi.
Ho scelto il classico (e noioso) esempio del Distributore Automatico. L'indubbio vantaggio, rispetto ad un esempio correlato al dominio dell'azienda (teleco), e' che tutti sanno di cosa si tratta.
Ho quindi riealizzato dei diagrammi per l'analisi dei requisiti (Use Case). Un diagramma per la domain analysis (Class Diagram) e uno State Diagram.
Per adesso manca completamente il detailed design perche' lo scopo principale e' quello di descrivere la domain analysis in UML ai colleghi del dipartimento di Mosca. Per vari motivi (principalmente legati allo schedule molto aggressivo) i russi non fanno nessun tipo di domain analysis. E adesso si stanno scontrando con l'estrema complessita' del sistema di cui non esiste una visione consolidata (appunto una domain analysis).
Mi chiedevo se questo esempio potesse essere usato come punto di partenza, e poi migliorato da te e dai partecipanti al blog, per poi riusarlo in tutti quei contesti dove e' necessario avere un esempio completo di design in UML (e.g. UML 2 Manuale di Stile).
bye
john boydon
It's a shame I dont' remember where, but someone said that applying any kind of practise is better than no practises at all.
In my opinion the simple fact of thinking to HOW you do something instead of simply thining to DO something brings improvement.
Applying an unuseful practise at least make you aware of the way you work, and increases your alertness. Maybe you don't need "pair programming", but the idea of extreme motivates you more :P
I give credit to Kent idea on a fact: "personalization wars" are a big obstacle: is easier introducing a full set of practises than forcing everyone to agree on a sub-set.
Fabio Bertone
In my opinion the simple fact of thinking to HOW you do something instead of simply thining to DO something brings improvement.
Applying an unuseful practise at least make you aware of the way you work, and increases your alertness. Maybe you don't need "pair programming", but the idea of extreme motivates you more :P
I give credit to Kent idea on a fact: "personalization wars" are a big obstacle: is easier introducing a full set of practises than forcing everyone to agree on a sub-set.
Fabio Bertone
# posted by 
: 4:05 PM
: 4:05 PM
John:
in effetti l'esempio del distributore lo uso anche io, in diverse versioni (distributore di bevande fredde o calde, di merendine, o un semplice cambiamonete, o un bancomat che alla fine e' sempre un distributore :-).
Lo uso pero' solo nel corso UML, non nei corsi di design, perche' in questi preferisco altri tipi di esercizi, strutturalmente piu' complessi. Il distributore puo' diventare "complesso" esaminandolo nei dettagli, ma e' strutturalmente piuttosto semplice.
Ha anche il pregio/difetto (ed e' bene avvertire gli studenti :-) di prestarsi magnificamente ad una modellazione con gli use case. Questo da un lato aiuta a spiegarli, dall'altro da' un falso senso di semplicita' / adeguatezza. Basta pero' spostarsi su qualcosa di diverso (un videogioco, powerpoint, ecc) e si capisce come le cose non siano esattamente cosi' semplici / adeguate.
Per quanto riguarda la modellazione collaborativa del detailed design: sarebbe un esperimento interessante, ma se dicessi di si (nel senso di una mia partecipazione attiva alla cosa) finirei per prendermi un impegno senza poterlo seguire (come mi hanno fatto notare :->, ho gia' troppe cose in perenne stato di completamento :-). Pero', se trovi il tempo di mettere in piedi un sito su cui discutere il problema, sicuramente lo segnalo qui nel mio blog, e se mi tenete aggiornato, posso segnalare anche le "major release" del modello.
in effetti l'esempio del distributore lo uso anche io, in diverse versioni (distributore di bevande fredde o calde, di merendine, o un semplice cambiamonete, o un bancomat che alla fine e' sempre un distributore :-).
Lo uso pero' solo nel corso UML, non nei corsi di design, perche' in questi preferisco altri tipi di esercizi, strutturalmente piu' complessi. Il distributore puo' diventare "complesso" esaminandolo nei dettagli, ma e' strutturalmente piuttosto semplice.
Ha anche il pregio/difetto (ed e' bene avvertire gli studenti :-) di prestarsi magnificamente ad una modellazione con gli use case. Questo da un lato aiuta a spiegarli, dall'altro da' un falso senso di semplicita' / adeguatezza. Basta pero' spostarsi su qualcosa di diverso (un videogioco, powerpoint, ecc) e si capisce come le cose non siano esattamente cosi' semplici / adeguate.
Per quanto riguarda la modellazione collaborativa del detailed design: sarebbe un esperimento interessante, ma se dicessi di si (nel senso di una mia partecipazione attiva alla cosa) finirei per prendermi un impegno senza poterlo seguire (come mi hanno fatto notare :->, ho gia' troppe cose in perenne stato di completamento :-). Pero', se trovi il tempo di mettere in piedi un sito su cui discutere il problema, sicuramente lo segnalo qui nel mio blog, e se mi tenete aggiornato, posso segnalare anche le "major release" del modello.
Fabio:
I'm afraid I've to disagree :-). Applying unuseful, or even "wrong" practices (I'm not speaking of XP here) makes people frustrated, unproductive, etc. So ultimately they'll do their best to sabotage the practice. Nobody wins.
Any method that is sold as "universal" is bull$#!%. Indeed, Beck is not trying to sell XP as universal, but he is (understandably) very generous about the applicability of his approach.
While I can see the risk of "buying" a method that requires heavy customizations (like [R]UP), I'm afraid blindly adopting a fixed set of practices it's even worse. Different projects and different organizational styles require different approaches. We simply can't develop (e.g.) mass-distributed embedded software using the same practices you can successfully adopt for an enterprise web application, deployed only once in a local server.
Well, we can :-)), but shouldn't :-)).
Post a Comment
I'm afraid I've to disagree :-). Applying unuseful, or even "wrong" practices (I'm not speaking of XP here) makes people frustrated, unproductive, etc. So ultimately they'll do their best to sabotage the practice. Nobody wins.
Any method that is sold as "universal" is bull$#!%. Indeed, Beck is not trying to sell XP as universal, but he is (understandably) very generous about the applicability of his approach.
While I can see the risk of "buying" a method that requires heavy customizations (like [R]UP), I'm afraid blindly adopting a fixed set of practices it's even worse. Different projects and different organizational styles require different approaches. We simply can't develop (e.g.) mass-distributed embedded software using the same practices you can successfully adopt for an enterprise web application, deployed only once in a local server.
Well, we can :-)), but shouldn't :-)).
<< Home
