Archive for the ‘book’ Category

Craftsmanship is not art and we care like craftsmen do

Wednesday, January 12, 2011
Drawers to Heaven

Some rights reserved, by Felix E. Guerrero

I’ve read Dan North post Programming is not a craft and I have to say that I have mixed feelings about it.

I’ve always been against recognizing beauty in software in general and in code in particular. I don’t think that coding is an art and I don’t think that any programmer can be characterized as an artist. Code has no aim beyond solving a problem and providing some utility to a user (where a user can be another system, an organization, etc., not necessarily the end user alone). Good code is code that solves a problem AND it’s easy to change, highly cohesive and decoupled, without duplications, etc. Bad code is code that doesn’t express those qualities. So it would be a stretch to talk about good code in terms of beauty, IMO.

And I agree with a lot more from that post. For example, I like and agree with the analogy of the samurai. And I do actually believe that: “It takes a real expert – a real craftsman – to see the elegant simplicity buried away inside the mess we call enterprise software, for instance, and tease it out.”

Having said that, I also disagree with his characterization of craftsmanship, especially in artistic terms. I think that our work, the way I see it, the way I do it every day, has a lot in common with what master craftsmen used to do in Italy during the Renaissance. And a lot of it clearly wasn’t art at all, it’s just good work well done.

Back in 2002, I had a lot of troubles trying to communicate to friends and family my passion about writing code. Passion is not even the right word, “care” is more appropriate. I do care a lot about the code that gets written. And for me, the idea that code must solve a problem, is a given. Speculative coding is like onanism: you get tired of it very soon. So, taking for granted that code must solve a problem, why do I care about how the problem is solved?

Literature to the rescue. In that period I was reading a book from Erri De Luca, callend Montedidio (by the way, it has been translated in English, I recommend it). A passage just drilled in my brain:

Mast’Errico mi ha messo a stendere il turapori e a carteggiare. Alliscio le ante di un armadio per vestiti. […] Oggi ha provato la chiusura della prima anta e quella ha combaciato così bene che ha fatto il rumore del soffio, l’aria se n’è scappata da dentro. Mi ha fatto mettere la faccia vicina al battente, ho sentito una carezza d’aria. […] Poi mast’Errico l’ha smontato e l’ha coperto, è un’opera importante, aggiusta tutta un’annata. I cassetti sono di faggio, gli incastri a coda di rondine, una soddisfazione vederglieli uscire da sotto le mani. Controlla gli squadri molte volte, ingrassa le guide, sfila e riinfila i cassetti senza rumore, come la lenza in mare, dice, che sale e scende muta in mano a lui. Mast’Errì, dico, siete un fenomeno, un ebanista pescatore.

A rough translation in English would be:

Mast’Errico put me to spread the filler and sanding. I smooth the doors of a wardrobe. […] Today, he tried closing the first door and it matched so well that it made the sound of the breath, the air has escaped from inside. It made me put my face close to the door, I felt a caress of air. […] Mast’Errico then has dismounted it and covered it, it is an important work, it fits an entire year within. The drawers are made of beech, the joints are shaped like dovetails, such a pleasure watching him crafting them with his hands. He checks out the alignments many times, he greases the rails, and he pulls the drawers back and forth without noise, as the line at sea, he said, rising and falling silent in his hand. Mast’Errì, I say, you’re a phenomenon, a cabinetmaker fisherman.

So, this is my take at software craftsmanship almost 9 years ago, recorded in a message to the Italian XP mailing list on 12/3/2002, years before anybody even started talking about it. 
My message back then ended with the following:

A software engineer is a postmodern version of a craftsman. The death of a craftsman can be violent (due to lack of competence, negligence) or because of starvation (overengineering, gold plating). When a technique is overcome a skilled craftsman must reinvent itself or die.

PS: I’ve stopped trying to explain to people my work. In a social context I typically say: “I work with computers”. If I’m really in a good mood I may even say: “I write software”. That’s it. I get less frustrated this way. 

Presentations, Tufte and the devil of marketing

Thursday, June 4, 2009

After having heard good things about Edward R. Tufte over the years, I’ve finally put my hands (and eyes) on one of his most famous essays: “The Cognitive Style of PowerPoint: Pitching Out Corrupts Within“.

The basic thesis behind the essay is that PowerPoint is a low bandwidth tool for technical presentations and it shouldn’t be used at all where data is more relevant than mere suggestion. While I don’t disagree with Tufte, I also believe that his ideas need to be put in context.

Tufte’s point is specifically aimed at technical presentations (emphasis mine, but maybe Tufte should have emphasized this a bit more). NASA’s example about the Columbia incident is exactly right to the point: when you need to present the result of a technical analysis so that others can make an informed decision, then I concur entirely that a confused and contradictory presentation poor in data and details is probably not the best choice. Creating a false sense of security is in particular one of the worst things that can be done, especially when dealing with rocket science (literally). The consequences can be catastrophic, to the point where people may die. Actually, they died, which is the saddest, incredible and absurd part of the story.

There are a lot of other situations though where distilling the essence of a system of thoughts can actually be quite effective or even preferable than to provide a deep technical analysis. Let me explain why.

I’ve found myself preparing and handling a few presentations in the last months about themes like the SOLID design principles, pair programming, javascript testing, Selenium, Hudson, Terracotta and others. I’ve experimented a few different formats:

  • Mind maps
  • Google Docs slides
  • Lightning talks with no slide at all, but a decent body of knowledge accumulated in a wiki (specifically, Confluence)

I would divide those presentations in 2 groups:

  1. On one side lie the coaching interventions, where some sort of surprise and dramatization can help a lot to get the message through. SOLID principles talks are definitely part of this category.
  2. On the other side, more technical presentation where the goal was to communicate the essence of certain technical ideas as quickly as possible, with enough reference to deepen the related body of knowledge in autonomy.

The former presentations work better if no details are handed over prior to the presentation itself. The surprise effect is quite important.
The latter presentations can benefit from having the audience reading some sort of a short technical report before. This way, the slideware material can be kept quite light, just a recap of salient points, and there will be more space for discussion during the presentation.

I think that I’m gonna try to prepare a brief report for presentations of the second type. This means of course a little more work on my side, but that is not necessarily the case. I remember having spent hours trying to distill the essence of concepts that would have been expressed more easily in prose. That effort would be gone. Moreover, I will require from the attendees to read the material prior to the presentation, whether it’s on Confluence, in code or any other medium.

I’m curious to see how it will go. Luckily, virtually none of my presentations can be characterized as pitches, so eventually there is space for experimentation without having to sacrifice your soul to the devil of marketing.

(more…)

Missing MethodTimer.computeTotalTime() in Implementation Patterns

Thursday, March 13, 2008

While preparing a review of Kent Beck’s Implementation Patterns book for stacktrace.it I stumbled upon a missing detail in Appendix A (Performance Measurement): where is the implementation of MethodTimer.computeTotalTime()?

I didn’t pay much attention while reading the book: Appendix A is one of my favourite chapters because you can finally see what Beck means in practice, but I haven’t really considered all the implementation details, only the overall philosophy. For the review I decided to go deeper and I couldn’t really understand what happened to MethodTimer.computeTotalTime(). In addition, until you realize how that method should look like, maybe you find yourself in troubles trying to fully grasp the design. I certainly did. Google didn’t help (I guess that Beck for whatever reason didn’t want to publish the code), so I did it by myself.

 private long computeTotalTime() throws Exception {
 	long start = System.nanoTime();
 	for (int i = 0; i < iterations; i++)
 		method.invoke(instance, new Object[0]);
 	return System.nanoTime() - start;
 }

This is not rocket science of course, but I had a few false starts before getting it (also because I made a few mistakes copying the code from the book and I was misled by the results). Hope it can help you as well.