Wednesday, July 30, 2008

Really achieving your childhood dreams: an insight by Randy Pausch

Yesterday I saw Randy Pausch's last lecture. It is quite long but every single second is more than worth watching.

Brick walls are there for a reason... and have YOU figured out the head fakes?

Friday, July 25, 2008

Revenge of the fat

<crap mode on>To all the people obviously so envious of my wonderfully shaped body... find here one more advantage of being fat!

ps can anybody help me? I cannot exit the crap mode...

Get in shape

Even if I already am in perfect (though spherical) shape, I'll post some tips as a reminder.

A simple rule is to divide the classical three large (I wish!) meals we're used to into five or six smaller meals; this will raise your metabolism helping you burn fat and will also make you feel less hungry. None of these meals should be eaten just before sleep, as your body will not burn the excess calories. And don't forget breakfast!

Another tip: eat slowly, as your brain is slower than you would like it to be, and it can take up to twenty minutes for it to realize you've eaten enough. A good technique I've succesfully used (and will take back) consists in putting down your fork on the table after each and every mouthful. Hey this also fosters your conversations!

Drink, drink, drink. I'm not pushing you to alcoholism - I'm the last person on earth that would do it - I'm talking about water. Cold water. It helps your body to regulate its temperature and to metabolize stored fat; moreover, it carries oxygen and nutrients to cells and regulates blood flow.

Cut down the calories: you don't need to eat a tenth of what you usually do, it is enough you give up unnecessary junk. Pity many times they're the tastiest things around...

Do not give up carbohydrates (complex carbohydrates are great) and try to eat protein at every meal, as they also help muscle growth.

And now the tiring part: exercise, exercise, exercise. Cardio really helps you, but unluckily you can't do it on your couch. D'oh... I just love the Homer Simpson Style so much...

Thursday, July 24, 2008

Quandoque bonus dormitat Homerus

Trying to finish PPP I found an error while trying the code for the Extension Object example, in the Visitor family (chapter 28). The title of the listing (page 415) states XMLPiecePartException, while a few rows later you get the correct name for the class, which is XMLPiecePartExtension, an XMLPartExtension implementer.

Tomorrow I'll drop a note to the publisher, but I haven't found an errata yet... gives you to think, doesn't it? anyway, as soon as I have a better Internet connection I'll look for it.

Monday, July 21, 2008

Pair Programming Reduces Productivity!

That would be true if the most time consuming part of programming was typing...

Martin Fowler

(thanks to Federico for the "original quote")

Thursday, July 10, 2008


We check our codebase against a custom set of PMD rules, but sometimes we'd like to ignore of some of them, tipically for IDE-generated code (e.g. hashCode ) or when overriding methods (e.g. methods throwing raw exceptions).

The best possibility we've found is tied to the built-in SuppressWarnings annotations you get in Java 5: if you want to ignore all PMD warnings for the hashCode method you simply have to add the line


before your method. If you want to exclude a specific rule you can use the syntax


while for more than a rule the line gets something like

@SuppressWarnings({"PMD.LongVariable", "PMD.DefaultPackage"})

The annotation can be applied to all the available levels: class, constructor, field, method, local variable, and so on and so forth.

You could also add the (customizable) comment //NOPMD on the same line for which you experience the warning, but it is much less elegant and powerful.

Tuesday, July 8, 2008

Divide et impera

Following this ancient rule (and Uncle Bob's suggestions) we recently separated our new development effort into four subproject, each of which focuses on a particular aspect of the whole project. The separation is also based on the techniques for splitting the different domain aspects explained in DDD.

Everything has been integrated in Hudson, with the Cobertura, Open Tasks and Violations (with PMD) plugins.

We still have to reintroduce JDepend, but we'll do it in a short while.

Friday, July 4, 2008

Estimation techniques

I posted some thoughts about it in this discussion.

Immortality close at hand

Tgcom published an article about death by lethal injections which states

...grazie alla nuova procedura con l'iniezione letale messa a punto dalle autorità, ci ha messo 12 minuti a morire, e non mezz'ora come le ultime volte.

which more or less translates in " only took him 12 minutes to die, while in previous occasions it took him half an hour". I do not want to comment on the article, nor suggest it is not about a very grave matter (no pun intended). I only whish they sometimes read what they write...

I definitely am against death penalty.


It is quite an old ad, but if you're lucky maybe the post is still vacant... hurry and apply!

Thursday, July 3, 2008

Is Refactoring a Necessary Waste?

In this article I found an interesting definition: necessary waste, which is qualified as "the best way we currently know how to do a job even if it does not have a customer value". Following this line Amr Elssamadisy says that refactoring - a necessary waste - is not valuable to the customer and that you should only "refactor code that no longer meets the requirements of the user".

I strongly disagree with Amr for a bunch of reasons.

The first and simplest of all is this one: refactoring eventually SAVES time, as once you'we written your software you AND many other people will have to read it. A complicated code thus implies more time needed to understand it, and probably much more time to safely modify it. And guess who is going to pay for it? Saved time IS valuable to the customer, as it translates into considerable money savings.

Leaving aside all other reasons and considerations you can find in literature, I'll have to add this one: I love clean and elegant code, just as I liked clean and elegant mathematics expressions since when I was at school; I strongly agreed with my regretted maths teacher, who used to value more students who presented elegant solutions. Unaesthetic code simply disturbs me. I'm not saying all my code is elegant and perfect (I'd like to, but it would be a huge lie), but that's what I aim to when I'm coding. This is one of the reasons for which I've joined the anti-if campaign (I hear an English version will soon be available so stay tuned on the site).

One caveat: if you're working on a piece of code and find something else that smells don't switch your tasks, even if the refactoring is (looks) trivial: just pen it down and come back later. I find it a much better strategy, or at least it is for me - and for mr. Kent Beck:

We'll make a to-do list to remind us what we need to do, to keep us focused and to tell us when we are finished. ... When we finish an item, we'll cross it off.

(Quoted from Test-Driven Development: By Example)

TDD being imposed in every quality discussion?

Following this discussion I posted my opinion on the matter.

When you have a "simplest thing that could possibly work" the first fit can be a good answer, but it could also be a horrible one. That is where refactoring comes in, and I must admit I'm pretty astounded that nobody mentioned it so far.

TDD means "let me think what this should do... ok I'll write a test that uses this class... there you have the class... ok it works... LET'S ELIMINATE ALL DUPLICATES AND SEE IF WE CAN SIMPLIFY IT FURTHER".

TDD helps quality not only because your software works, but also because it is simple and easy to understand (then to modify). TDD should not be imposed in every quality discussion, but it surely is a very good means to reach quality; writing tests surely is time consuming, but it is well invested time: you're paying for quality. As Philip Crosby said, quality is free but only to those who are willing to pay heavily for it. That's why also Clean Room works, because you're willing to pay.

To quote,

code quality is a function of thought and reflection, not bug prevention.

Sadek Drobi replied that

Code quality is not only about code simplification, but also and most importantly about reflecting correctly the domain (see DDD). TDD is applied to units, you can not build a coherent quality code while thinking locally. That is why TDD is not the "Tool" to quality code. Quality code is a result of good design skills (thorough domain analyses), a lot of discipline, and Functional tests.

TDD is not necessarily applied to units (I know I wrote on InfoQ that I agreed, but I was thinking of Unit Testing and not about TDD), but it's true you cannot build a coherent quality code while ONLY thinking locally. But it surely helps, and this is particularly true if when Sadek talks about functional tests he is referring to automated functional tests.

Sadek then pointed out how TDD is about short cycles and thinking locally, supporting this idea quoting Beck, and stressing the point that TDD does not produce quality code per se and reiterating the importance of design skills, domain analysis, discipline and functional tests.

Again, I agree with him: TDD surely helps to produce good code but is not "the" tool. I mean, if you have a perfectly analyzed class which perfectly represents a domain object (I'm fond on DDD too) but you find it difficult to be tested, probably there is a slightly different and slightly better metaphor to describe it (and maybe an SME can help in defining it). Being able to write a test for a class before actually writing it kind of "forces" you to have an attitute just like the one Sadek describes: you have to analyze the domain with a lot of discipline, because with TDD you are actually saying "what am I expecting from this piece of code? what is the expected behavior of the real object it represents?". Of course, you must also have funcional tests, and having good design skills is almost mandatory, otherwise one would blatantly miss the point of the whole question.

Voting Someone Off the Island on an Agile Team

I read an interesting post on voting someone off an agile team; you can only do it if you work in a self-managing team, just as it should happen when adopting agile methods. I pretty much agree with the practice, given that the outcast has been given enough time and support by the other members of the team to adapt.

Sometimes it can be very difficult, for example in small realities: if you work in a little firm and maybe there's just one team voting a member off pretty means having her fired, with all the consequences... but would that be wise? The (ex) team member might be a very good professional, and bring substantial benefits to the company, for example she can have good testing and problem solving skills, thus considerably shortening defect fixing time. She could also be a very good programmer and effectively contribute to the codebase. Only she would not fit in the team. In these cases you can be saved by the fact that in small firms you have to do pretty much everything, from screwing a second NIC on to your motherboard to planning for the next release with the customer. It can then be easy enough to factor out something for the "outcast", but you should be very careful dealing with the "human" part of the transition, you just can't say "hey you're a burden for the team, they don't want you to work in their projects, but you should stay in the very same office." After all, even if some technical people would strongly disagree, the most important thing for a team to be a good team is not technological eccellence but the chemistry of the relationships between the team members.

You want everyone to be happy while at work (also when they're off work, but at least that is not your responsibility) so you must act with intelligence and find the right solution.

Sometimes the right solution is just a sacking.

(Thanks to the site Implementing Scrum for the picture)