The Craftsman’s Dilemma
The programmers I know who have been in this business for any length of time have a strong trait of craftsmanship: they genuinely care that they produce software of high quality, lasting worth, and beauty. I think that this is a necessary quality for this business, because there’s not enough job satisfaction to sustain you unless you can take pride and pleasure in the artifacts you make. Certainly I’ve got a strong compulsion to produce beautiful code, even if I have to spend my own time bringing it up to my own standards. I argue that this isn’t an optional quality - programmers who lack this drive and get by with software that merely meets specification soon get a reputation for carelessness and are driven out of competition by those who are compelled to put in the extra effort required to build truly great software.
But the craftsmen of the trade are in a dilemma. On the one hand, employers value them when there is new software to be built, because they know that the software will be of the best quality. But on the other hand, there isn’t much place for the craftsman’s aesthetic once the software is written, debugged, and released. When the shouting is over, the software goes into “maintenance and enhancement,” and success is judged by different criteria: keeping the software stable and adding new features in the most efficient way. Usually, these new constraints introduce a new set of compromises that frustrate the craftsman who - still - wants to produce a thing of beauty and a joy forever. So, it’s not unusual for the craftsmen to silently slip away from the project shortly after it has shipped and after it is turned over to the “sustaining engineering” crew.
Is there a solution to this dilemma? Is there a way of keeping the craftsmen engaged through the life of the product? I’ve been searching for a solution for most of my career, because I hate having to leave behind something that I’ve spent so much time and energy on. But I’m not sure that there is a feasible solution, because the goals of the employer are so much at odds with the craftsman’s goals. The employer wants, above all, to make money on the product - and this requires stability in the code base and rapid reaction to customer demands; and the craftsman wants - still - to practise his craft unrestrained. As I say, competing value sets lead to no solution.
Still, the craftsman can’t (or shouldn’t) complain - the joy of creation is (or should be) reward enough, and having to move on to the next green field is the price we pay for getting to create beautiful things.
