That is an oxymoronic title, with the words “Craftsmanship” and “Management” side by side! Isn’t the essence of craftsmanship skilled individuality? While management is the process of controlling people? Is there not a contradiction of terms here? What is this all about?
If you are in the business of making software, the fundamental process of creating software is really simple: it is just about transforming some idea into executable code. Behind the simplicity of this idea, though, there is a whole universe to be discovered. It is almost expected that any software project will miss out on scope, budget or time. Why is that?
For the solo programmer, the process is straightforward: thinking and coding are just two sides of the same coin. As soon as more than one person is involved, the ideas that need to be transformed into executable code need to be communicated between the participants – and this is when things start to break down.
Imprecision and Vagueness of Human Communication
While human communication can easily survive the imprecision and vagueness of expression that we deal with on a daily basis, any imprecision and vagueness becomes detrimental when transformed into code. Legendary programmer Donald Knuth in an interview [SHUSTEK-2008] expressed this very neatly…
When you’re doing programming, you have to explain something to a computer, which is dumb. When you’re writing a document for a human being to understand, the human being will look at it and nod his head and say, "Yeah, this makes sense." But there are all kinds of ambiguities and vagueness that you don't realize until you try to put it into a computer. Then all of a sudden, almost every five minutes as you’re writing the code, a question comes up that wasn't addressed in the specification. "What if this combination occurs?" It just didn't occur to the person writing the design specification. When you’re faced with doing the implementation, a person who has been delegated the job of working from a design would have to say, "Well, hmm, I don't know what the designer meant by this." [...]It is so hard to do the design unless you’re faced with the low-level aspects of it, explaining it to a machine instead of to another person. […] you don’t really understand something until you’ve taught it to a computer, until you’ve been able to program it.
What has This to Do with Business Results?
In the corporate landscape, there are legions of managers, stakeholders, business analysts, customers, project managers, product managers, marketing managers, VPs, CxOs and other professionals and intelligent people that all want to tell the software developer what to do. There is this undeniable need of producing software originating from ideas that have been conceived of by non-programmers; and hence the need of communicating those ideas to those who know the craft and can transform them into executable code.
Yet, no matter what and how those ideas are expressed and communicated, that expression and communication will be insufficient. This insufficiency is the root cause of many software project failures. What is worse, is that this insufficiency will reveal itself only when the programmer will actually try to… program.
Programmers are Not Mechanical Coders
The problem is further exacerbated by a frequent misconception: that the programmer’s job is only that of “translating” those ideas into “code.” The programmer’s role is dumbed down to that of a mechanical coder. Donald Knuth relates the following:
Edsger Dijkstra gave this wonderful Turing lecture early in the 1970 called "The Humble Programmer." One of the points he made in his talk was that when they asked him in Holland what his job title was, he said, "Programmer," and they said, "No, that's not a job title. You can't do that; programmers are just coders. They’re people who are assigned like scribes where in the days when you needed somebody to write a document in the Middle Ages."
The role and title of “Programmer” is often considered as denigrating, belittling. This reveals one fundamental misunderstandings of what programming is about: the belief that it is possible to specify a design, and that programmers are “just coders” that can translate that design mechanically into a program. (If that were true, programmers would not be needed – computers could do their job in the first place.)
People who hold this misunderstanding, typically have never been exposed to the realities of programming. They cannot relate to the experience in the trenches, as described by Donald Knuth.
The Resistance of the Medium
They have lacked the “resistance of the medium” as expressed by Paul Graham [GRAHAM-2006]. For Paul Graham, the program that is being created, is a medium of expression; and like all media of expression it exerts resistance to being shaped – much like a block of stone or marble resists being shaped by the sculptor.
Increase the Friction!
Paradoxically, to get better performance from your software development organisation, one of the best strategies is to increase the friction between all professional roles involved. Many of the Agile software development processes gain better performance precisely because of this mechanism. They create more opportunities for interacting, discussing and exchanging ideas than what is customary in other, more plan based approaches.
This is just one of many unintuitive concepts that characterize hyper-productive software development organisations: they deliberately increase the friction between all people who have anything to say about the software being developed. It is through these opportunities of interaction, that the resistance of the medium experienced by the programmer is related back to those who programmers are not. By making the resistance tangible, there are more opportunities to arrive at the desired shape.
Understand the Nature of Software
Software Craftsmanship Management is about how to manage the relationship and the communication between those that have an idea, and those who know how to craft that idea into running software.
If you are a business owner or a manager, and need to get the maximum performance out of software development, then understanding the nature of software is a necessary first step. Increasing the internal friction in the organisation is just one of many winning concepts. We will explore this topic further in subsequent posts.