The analogy of software developers as craftsmen has become very popular. I don't know where it started, but the first book I read about it was the excellent book The Pragmatic Programmer by Andy Hunt and Dave Thomas. I really liked this analogy, it seemed right.
A few years later, Pete McBreen released the book Software Craftsmanship, where he articulates that software development should be more like craftsmanship. Pete writes eloquently about programming masters that should be paid ten times more than their apprentices because they are at least ten times more effective. The masters also have the responsibility to take on journeymen and apprentices to train in their particular flavor of software development. This also rang very true to me.
But, there is something fishy with this analogy. Something ain't right!
I have come to understand that the analogy refers to how it is believed that the craftsman "industry" worked ages ago, rather than how it is today. If you hire a carpenter today he may tell you that he will come "sometime next week". I have rarely been given a time that is more exact than a four hour span, to just meet up.
After the meeting has been scheduled, I have to be very lucky if my craftsman actually appears at the appointed time. Most of the time he will not show up at all!
If I happen to be lucky enough to get a craftsman to show up or to call and tell me that he can't make it, I usually make a note of this guy as being, a highly reliable craftsman, worth hiring again. He gets a golden star for just calling to tell me that he won't come.
When we finally meet up, the craftsman may do a terrific job and I will happily recommend him to anyone, but most likely we will talk and he will tell me that he doesn't have the time to do the job right now, but that he can come back tomorrow. If you let him go with that, he most likely will not come back tomorrow or the next day. He will come back when you call to remind him that he should have come back. And even better, if you pay him in advance you will never see him again, ever!
So, if our goal is to get programmers to be viewed as craftsmen, we're already there. Just change the statement those f***ing carpenters never do what we expect! to those f***ing programmers never do what we expect!
Maybe the whole idea of programmers as craftsmen is just:
It was better in the old days.
It wasn't, it is better now!
I have learned one thing through all my years of programming:
The more I learn, the more I learn how little I know. --Socrates
I'm not a software craftsman, I'm a humble programmer, a good one, and proud of it.
Anders Janmyr
Consultant at Jayway
3 comments ↓
I think it is a cute movement.
Here is a nice very recent podcast from SE Radio on the subject:
http://www.se-radio.net/podcast/2009-11/episode-150-software-craftsmanship-bob-martin
To me, there is nothing really new to it though…how unusual…
My point is, that when you choose an analogy, you cannot only choose the parts you like. Someone else may draw different conclusions than you do.
Interesting point of view.
In a way I can see what you mean, that it is important not to be taken in by the romantic idea.
But in other ways I disagree, what would keep you from adopting features you like and dismiss others in a method of working?
I don’t see how unreliable scheduling and poor communication is a mandatory side-effect of craftsmanship.
Even if we assume that this is the average work ethic of a typical craftsman, it could be attributed to culture or economics, or some other influence.
I would more easily agree with arguments such that it assumes the master willing and able to teach, and the journeymen interested and inspired to excel.
For that segment however, I don’t think it’s a bad read.
(Colleague at Jayway)
Leave a Comment