Craft or not? Dan North rejects the Manifesto for Software Craftsmanship

The very good classification of developers was done by Karel Capek in The War with the Newts in 1936. Originally it was about newts, but it really works:

• 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...
  

I think the word craft is the exact one reflecting the very nature of software development. The process is a very intellectual one and very similar to the traditional craft job, exception we are using keyboards and mouses, instead of hammers and saws.

Why do we need to classify software development into any other category? Why can't it just be Software Development or Programming? And the people Software Developers, or Programmers?

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.

Clinton
Programmer

"As Dan further concludes, the industry needs an apprenticeship model with masters educating apprentices." Isn't already what Software Craftsmanship is all about? "As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft".

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?

I see the writing of software as a formal expression of ideas. We are translators. We take the ideas in peoples heads and convert them into something a computer can understand. Hopefully our translations are good enough that someone can pick them up later on and understand them.

I love this!

"... whether software engineering is an art, a craft, or a science."

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.

Keith

Comparing programming to more physical forms of labor is a way to highlight some of the challenges we face as programmers. The effect of sloppy coding is real, but its cause is hard for the untrained eye to see. Many managers can't understand why working code is not always sufficient. Analogies of this sort can be an effective tool for translating the gist of an issue into a form others can relate to, especially when trying to explain it to non-technical people.

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.

Peter,

This is fantastic! The classification sits so aptly on the the vast population of 'software techies' that I hear about! Thanks for sharing.

-- Nirmalya