Software craftmanship

Gojko Adzic has taken the bother to go through the Hudson/Jenkins code base and critique it. He doesn't find the code to be pretty, and wonders what impact this might have on software craftsmanship.

I found the comments quite good. I wrote my own lengthy response, which I am going now going to quote, as I want to add a footnote.

"Any long lived piece of code is going to have many people working on it, each with their own unique style and understanding of the code base. 

Every piece of functionality added is going to have it’s own motivating circumstance, so, for example, there might be time or financial limitations driving it that we, the code readers, are not aware of.

It is almost always easy to criticize others code, but without insight as to how that code was created and added to, the criticism is, to me, shallow. It perhaps gives us insight into the critics preferred coding style, and also maybe teaches us a little.

But beyond that, Hudson/Jenkins code works. The Hudson/Jenkins is released often. The Hudson/Jenkins is very popular. I think that is the true test of software. Regardless of our personal feelings on reading the code. 

You ask where does this code leave software craftsmanship? Hudson/Jenkins is the rock on which many continuous integration projects are based, so I guess it seems to show that software craftsmanship is really not as important as releasing early, releasing often, and getting immediate feedback from a wide community of users. That seems to trump code ‘quality’.

But you know what? It does look as though they could do with a little help cleaning that code base up. We should start by contributing some tests…"

The footnote:

I'm with Dan North. "No-one wants your steenking software – they want the capabilities it gives them."

The only craftsmanship the user of an application will experience is via their interface to the software. It is one of the oddities of the software world that we can write a perfectly literate, indeed beautiful, program that is totally unusable.  And as Hudson/Jenkins seems to show, we can write an abomination that is extremely popular, well liked, and very, very important.

At this moment I believe that the software craftsmanship manifesto is by developers, for developers. If it were any other way it would have usability and interaction at its heart, not code.

What software craftsmanship seems to offer is code that more reliable, cheaper to build, and if it passes the first hurdle of customer acceptance, easier to maintain. That's not bad: but I find myself wondering how many of its practices are well founded.

Take the 100 line constructor that Gojko complains about: in Code Complete, Steve McConnel writes "Decades of evidence say that routines of such length (>100 lines) are no more error prone than shorter routines. Let issues such as the routine's cohesion, number of decision points, number of comments needed to explain the routine, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. That said, if you want to write routines longer than about 200 lines, be careful."

Surely we should forgo our beliefs in favor of research results?

During my career as a software developer I have seen fads come and go. Many seemed to have very little scientific underpinnings, being based more on belief than on reality. I worry that, seductive and appealing though it sounds, software craftsmanship might be in the same boat.