Wednesday, July 11, 2007 

Get the ball rolling, part 1 (of 4, I guess)

A few weeks ago, I got a sad email from a reader. It was about some people around him bashing UML, and more generally, diagrammatic reasoning.
This is not big news: some people just don't like modeling (for various reasons), and in the last few years they've also found fertile ground in several "agile" precepts.
Indeed, his colleagues just sent him a link to Engineer Notebook: An Extreme Programming Episode, by Robert C. Martin and Robert S. Koss. Somewhere around the end, RCM says "We were bedevilled by the daemons of diagramatic overdesign. My God, three little boxes drawn on the back of a napkin, Game, Frame, and Throw, and it was still too complicated and just plain wrong." His colleagues sort of wanted this carved on his tombstone :-).

Now, I've been reading Robert Martin's works since the mid 90s. I've enjoyed several of his papers, and I've even published a couple of papers in C++ Report when he was the magazine editor. I must admit, however, that although I own the book from which that paper has been derived, I just skimmed through it. So, before saying anything, I did the right thing™ and read the paper carefully. Truth to be said, I found that paper laudable, because by providing a realistic example, Robert gives us an opportunity to tackle the same problem in a different way, and compare the results.

Of course, the problem is on a very small scale, so someone could complain that it's not the kind of setting where diagrammatic reasoning shines. That would be a lame excuse, so I won't say that.
I won't even question the fact that they both knew Bowling quite well, and that therefore the dynamics isn't really representative of what they can do in an unfamiliar domain (in fact, there is no user's involvement in the XP episode). Of course that's quite relevant, but what the hell, I can learn bowling rules in no time :-).
I won't even try to assess whether they were faithful to the XP principles or not; it seems to me that they did it just fine: they kept the emphasis on working code, did some refactoring, wrote tests first, applied pair programming... seems like they're doing it by the book.

Still, I do have issues with the quality of the results, and I do have issues with the conclusions. I'll save this stuff for my next posts. Meanwhile, I really urge you to read the paper. It may put you off a little if you don't know/play bowling (I don't :-), but it's a worthy exercise. Read the code, see if you like it. I'll see you in a few days :-).

Note: this is not going to be a theoretical, wishy-washy, hand-waving blurb. I can play theories, but in this case, it's much easier to play code. In fact, one year ago or so I posted a simple challenge for the TDD crowd. I basically got back theories, insults, and the like, but no one wrote any damn code (except in the end, when a good guy did). I'm an action guy :-))), so I'll just show you what I don't like, how I would model and implement the same thing, and compare the results. Actually, maybe you wanna give it a try too!

Labels: , ,

it's gonna be fun!
Ho dato solo un'occhiata all'articolo, solo mi chiedo come mai arrivano a formulare correttamente le regole solo a più di metà articolo??? :)
La prima volta che ho giocato a bowling ho formulato correttamente le regole ben oltre la meta' della partita! :-)
Condivido la perplessita' di Fulvio (se non voleva solo fare una battuta): fa parte del loro stile passare subito alla pratica? "Fammi vedere del codice se no non capisco" mi ricorda il "dimmi la soluzione non voglio il ragionamento" degli scolari sbrigativi.
no, in effetti non era una battuta, se si leggevano wikipedia magari l'articolo era lungo la metà. Per il resto sono ansioso di leggere le altre 3 parti, i guess ;)
Fulvio, Citrullo: in realta' mi pare che i due autori si siano comportati con onesta' intellettuale. Volendo mostrare un approccio XP, che in pieno stile agile ha tra i suoi valori "Working software over comprehensive documentation ", non hanno fatto affidamento su una base di conoscenza "documentale" esterna come wikipedia o altro.
La pecca, come dicevo, e' che in realta' loro conoscevano bene il problema (quindi di quella base documentale non hanno realmente avuto bisogno), mentre in un caso reale avrebbero dovuto interagire con un utente / committente per comprenderlo. Pero' "passare subito alla pratica", "progettando" attraverso la scrittura di test, rifattorizzare il codice, ecc ecc, e' parte integrante dell'approccio XP che vogliono mostrare. Non a caso questo esempio e' stato referenziato parecchio (google trova circa 240 reference).
Post a Comment

<< Home