Friday, January 20, 2006

The Mystique of Software Craftsmanship, Part 1

Usually, the first years in the professional field of information technology are all about geeky concerns and simple delights like learning languages and exploring frameworks. Then come the big questions about what and why and how are we doing what we are doing. Technological questions give way to human interrogations.

It not a benign fact that information technologists are dealing now with such questions: the industry have matured to such a point that everyone knows that any new technology, as complex as it could appear, can be tamed and that the true challenge lies in the intricacies of human behavior.

Being aware of the challenge that sits in the very heart of each of us is the only way to be able to work on it. Common concepts like rigor and willingness can surely help us improve ; I would like to propose to everyone of us some disciplines whose practice should contribute to improve our craftsmanship.

First Discipline : Taming the Unagile Old Man

Why do we sometimes catch ourselves wondering if we really should code to interfaces instead of concrete classes? Why are we from time to time erring in thinking that we can skip writing this unit test? Why are we tempted to forget about refactoring code that works but we know would be hard to maintain? Why is our first reaction to a change request a negative one?

All these questions lead us to wonder if there is there such a thing as an unagile old man? Similarly to the old man of the Christian faith, who represents the natural tendencies of the non-spiritual human being, the unagile old man would manifest from time to time, when tiredness level or deadline pressure is getting too high, and he would try to carry us in the infamous water of compromising with quality.

What, as software craftsmans, can we do to tame the old man? We have to learn his tactics and apply counter measures:
  • if he plays on your fatigue, get some rest or go out for a walk and come back to the problem,

  • if he tries to scare you, increase the test coverage of your application and take revenge by refactoring aggressively,

  • if he invites you to cut corners, repeat Robert Martin's mantra: “the only way to go fast is to go well” until he gets deaf.