Craft or not? Dan North rejects the Manifesto for Software Craftsmanship
In recent blog posting Dan North, well known expert for software engineering and employee of DRW Trading, explains his rejection to the Manifesto for Software Craftmanship. The manifesto had already been covered by Mark Levinson in a previous infoQ news article.
Dan does not reject the value of a manifesto for software craftsmanship, but prefers calling programming a trade not a craftsmanship. He suggests reconsidering and rewriting the manifesto on the one hand, but emphasizes on the other that he does not object to let passionate and highly qualified developers differentiate themselves in some way.
Calling the profession “software craftsmanship” would shift the focus too much from delivering value to software. As he puts it, “Programming is about automating work”. There is no required education such as in other professions, and some excellent developers never experienced any education in programming skills, but rather “have a flair for it”. According to the blog author, companies like Microsoft have even tried to lower the entry barrier for becoming a programmer by providing languages such as Visual Basic. He claims most people in the IT Industry went there for high incomes combined with the low number of skills or experiences required to become a software developer.
As Dan further concludes, the industry needs an apprenticeship model with masters educating apprentices. He tries to illustrate that software engineering is not a craftsmanship but more a utility by comparing it with constructing small bridges as opposed to creating cathedrals where properties such as beauty are important.
This posting raised some immediate responses in the community and among the readers of the blog. According to Dan 20000 people visited his blog and 150 people left comments causing him to add a second posting dealing with some issues brought up by readers.
The following examples are supposed to give an impression about the diversity of reactions.
Guillaume disagrees that software programming is not a craft. He believes Dan has fallen into the “#1 trap when talking about software development, which is to draw a parallel to masonry work”. As Guillaume further adds, software engineering “allows so many solutions all ending up with working software, it’s difficult not to see craft.”
From Kris Randle’s perspective the posting misses the point because “a lot of the parallels are weak, and there is nothing other than the writer’s opinion to steer the argument.”
Steve Tooke welcomes the blog posting as a thought provoking piece, but wonders why Mr. North considered the software craftsmanship community “the prima donna”. In his opinion, the proponents of the software craftsmanship manifesto already discussed most of the issues Dan brought up. “If you look at some of the talk outlines from this year’s SCNA: http://scna.softwarecraftsmanship.org/schedule I feel there is plenty there that resonates with what you have written here.”
Joca Torres generally agrees to Mr. North’s blog posting and suggests a way to choose a software professional: “The best way to choose a professional – a software developer, a medical doctor, a plumber or any other professional – is getting references and checking her past work.”
Another kind of classifying developers is proposed by Jack Repenning. He identifies Open Source Software Development as a possible means for differentiating programmers. As Mr. Repenning claims, open source developers are “the lovers-of-the-craft” while other developers are more motivated by income.
Niclas Lindgren does not agree with all of Dan’s arguments. He considers skilled developers to be craftsmen: “Actually the definition of a trade to me is that you have skilled craftsman doing it. I know this is just wording, but it is important as you trying to distinguish trade and craft.”
The initial posting of Dan as well as his reaction on the large number of reader comments, still keep attracting readers to add their own thoughts whether software engineering is an art, a craft, or a science.
I don't like the term craft
Software engineering “allows so many solutions all ending up with working software, it’s difficult not to see craft.”
As in any engineering disciplines.
My main beef with the word craft is that it refers to a manufacturing process while software development is truly a product development effort in the end. As I see it, the general meaning of the word crafting is to build stuff manually, the opposite of an industrialized process, something that just don't make sense in the software world.
Classification of developers from 1936
- Leading means simply the specially selected, most intelligent newts, ... They are sold individually...
- Team are the ordinary working newts, ... they are sold only in working groups (teams) of twenty; they are intended for use together on major tasks ...
- The Odd Jobs constitute a class of their own. These are newts that, for one reason or another, were never trained for collective or specialised work. This could be because they grew up outside the large specialist newt farms run by specialists. They are, in fact, half wild, but can often be very talented. They can be bought individually or by the dozen and can be used for various kinds of supplementary or minor jobs ...
- The Trash are the less valuable newts... They are not sold as individuals or in squads but in bulk by weight, typically several dozen tons at a time...
Re: I don't like the term craft
Why do we need to classify everything?
Is Software Development not broad and deep enough to simply be its own thing? Has it not made as large an impact on the world as science, engineering or industry? Indeed, a lot of really bad software designs and practices can probably be attributed to attempts to compare software to building construction, or chemistry, or carpentry or even math.
I'm a big believer in using analogy and comparison to explain concepts, learn new concepts and even create new concepts. But because I am able to use an engineering analogy does not suddenly make software an engineering discipline (or science or craft...). Yet, indeed these things all work together. How did the science of plastics change engineering? Did math not help them prove how? Software Development will be a good neighbor as well -- each discipline learning and evolving through the others.
The danger with classifying software development as anything else is that we may unintentionally create artificial constraints around our discipline that don't allow for the creativity necessary to speed innovation. I'd rather leave the field open. There are no rules made for software development outside of those created by the domain and culture of software developers.
Let's just end the debate, call it Software Development, or Programming or whatever -- something all its own. And let's ensure that the professors in schools are purely students of Software Development themselves, and not engineers, mathematicians or scientists. There are already programs, courses and careers for those disciplines.
Re: I don't like the term craft
Conrtradictions and useless polemic on a positve movement
I perceived this movement as really positive by encouraging developers to care about their craft (skills and knowledge), by using the right tools and keeping a professional ethic. I particularly liked the analogy with classics crafts while crafts are disappearing in today's culture of let's-build-cheap-and-fast for quick ROI, which is true in every other industrial sectors as well.
Whether or not writing systems is like building cathedrals, the analogy of Craftsmanship brought something important and positive to programmers, some identity relieving from the sickness of maintaining rotten systems that turned our work into a day to day nightmare in environments with a minimal-code-changes, refactoring-is-dangerous and we-don't-care-about-TDD culture. This kind of management ignorance is not only bad for our sanity, but it also lead companies to huge technical depts.
To answer Clinton's question. We need to classify in order to differentiate programmers who don't give a damn about who will get to maintain their mess as opposed to those who really care about their craft!
Anyways, who cares about Dan North's opinion?
Software development is not a craft
There all right...
I would have to say it's all three. As comments in the article point out, there is a wide array of experience levels classified under the term programmer/engineer. Some are formally schooled while others, as Dan North puts it, “have a flair for it”.
I think anyone in the field can certainly agree there is a large difference between simply getting the job done and getting the job done with some expertise. Simple designs are largely procedural while more advanced designs take modelling, performance, and other factors into consideration.
The discipline is a craft (or trade - synonymous in my opinion) as we are paid to perform the work. It's a science as it depends on the principles and output of the computer science field, and an art for anyone who has taken the time to apply best practices of the field in their efforts.
It's a metaphor...
I have never been able to understand why businesses so often pressure programmers to cut corners to meet deadlines, consistently rewarding quick hacks over robust well thought out designs. From my vantage point, they don't seem to exhibit this degree of short term thinking in other areas (at least not to the same degree). I believe it's due to a lack of understanding regarding (a) what goes into making quality software, and (b) the long term cost of doing it wrong the first time.
The craftsman metaphor is not intended to be an exact description of what we do in every way. To take it literally is to miss the point entirely! It's important for us to have [non-technical] words we can use to describe the differences between code that is undisciplined versus code that is well organized, and the people who create it. There is nothing else we can point to. Education doesn't always make the difference; plenty of well educated software engineers turn out unreadable, unmaintainable code. Experience is helpful, but only to those who consistently try to improve "their craft". In the end, the mark of a craftsman is quality work (that takes time to produce), and that is the point that this movement is driving at. In this regard, I think the craftsman metaphor is useful.