Principles and Rules

Some weeks ago I gave a talk at AgileDay.it. My talk was about a weird experimental Kanban board, and the Leitmotiv I used was around the differences between Principles and Rules. The topic was: we often learn methodologies mocking rules (often, without getting the point) rather than trying to understand the principles behind them. This bad habit sometimes leads us to take really dumb decisions.

Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.

See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.

Best of #MovieLinesInCode

var it = new MP3(); sam.play(it); sam.play(it);
@chrisoldwood

$Apocalypse = now();
@johnnypixel

10 IF ALL WORK NO PLAY
20 THEN JACK = DULL BOY
30 GOTO 10
@andrewfconex

c.beginPath(); c.fillStyle="#0f0"; c.lineTo(63360*72,0); 
c.stroke();
@adomas_s

echo $bible['Eze'][25][17]; kill();
@arialdomartini

git and the Art of Visualizing Information

I’m in love with git, and I’ve been devoting a lot of time and efforts in promoting it in the companies where I used to work.

I always found hard to effectively communicate to TFS, svn and cvs users the paradigm shift that git requires. Depicting information and ideas turned out to be the most successful approach.

Yet, visualizing information is an art.

About Epic Framework, DDD and Declarative domain models

Giacomo Tesio wrote an interesting post after a question arose during the DDD Day in Bologna on October, 8th.

He proposes an appealing point of view about what programming is and what’s the Domain Expert’s role in respect to “the problem” and “the matter“.

I still have to think it through. I’ll write about this topic in the next days.

Thanks, Giacomo for giving me food for thought.

Event sourcing and git

I attended DDD Day in Bologna, last Saturday. Greg Young was really amazing and effective in introducing Command and Query Responsibility Segregation and Event Sourcing to the audience.

Property o Get Method?

Se il codice dietro un getter dovesse diventare particolarmente elaborato sarebbe più corretto spostarlo dentro un ordinario metodo? È corretto che un accessor method (cioè un metodo che, almeno idealmente, dovrebbe servire per esporre un field dello stato interno della classe al mondo esterno) faccia elaborazioni non banali, come visitare un grafo di oggetti?

Cercando una risposta a questa domanda (probabilmente futile ed accademica) possono essere fatte alcune considerazioni forse poco prevedibili.