Software Craftsmanship - can we just get over it?
A few times recently I’ve tweeted on Software Craftsmanship, and my concerns about the form the current emphasis on craft is taking. I’m still trying to understand what it is about the movement that — actually — alarms me. After all, how can anyone be against craftsmanship? That would be like being against world peace, or saving whales, or open government…?
Of course, I’m not against craftsmanship. Professionalism, taking responsibility for work, a dedication to improving one’s knowledge and skills: these surely have to be taken as a given — not just in software, but for anyone working in any domain where value is ascribed to the end result of activity. What’s more, and obviously, neither the practice nor the literature of what’s now being called software craftsmanship is new — think Knuth, Meyer, Bentley, Sedgewick, Beck, Lea, Kernighan/Pike, Hunt/Thomas, and many many more.
I have a problem with the language of software craftsmanship. The notion that somehow we’ll solve our nascent profession’s problems by calling ourselves, or regarding ourselves, as “apprentices”, “journeymen”, “masters” and so on is more than faintly absurd. The irritating language hides a deeper issue, and I think this is what’s struck me forcibly, recently, and which is why I’m now even more convinced that it’s more than misguided — it’s dangerous.
Building a community of practice around technical skills is guaranteed to lead to a “guildification” of the field.
The implicit (actually, sometimes explicit) appeal to form guilds suggests the romantic mediaevalism of fantasy literature, and an appeal to some sort golden age of craft that would deny both the issues and the opportunities that exist in the grown-up world of now. Increasingly, however, the interesting conversations, both for individuals and for organisations of all sizes, are about breaking down barriers — between companies and their markets, development organisations and the businesses in which they’re embedded, software developers and the users of their software. The imperative is to become more professional with respect to our markets, businesses and users, and we will continue to be isolated as a profession and as individuals within our businesses and our communities for as long as we persist in adolescent self-absorption.
We’ve seen this happen before. The patterns movement in software is an example: what started as a great attempt to forge some common vocabulary and understanding, and to ground both software design and organisational thinking in observed practice, very quickly settled down into a network of conferences, publications and smaller groups in which the forms of what was being done took precedence over the value of what was being produced. It became inward-looking, self-serving, and self-sustaining. (Oh, and please don’t get me started on anti-patterns…)
Agile is not immune: the explicit separation of concerns between business and development that’s bound up in the way agile roles and activities are defined. Before anyone shouts, I know that Agile is predicated on collaboration, and delivering value, and indeed in the 30% of teams I see where it’s working well, that’s just what happens: where interaction with a customer/product owner really is constant, and the conversations on priorities really are about customer priorities. But how common is that? For the other 70% — schmagilists, not agilists — the focus of agile on development and team practices, and the belief that someone else is responsible for caring about customer prioritisation, gives them the supposed freedom of not having to think about the business context of their work.
So at best, it’s not enough: at worst, it’s another reason for developers to convince themselves it’s not just OK to ignore the context of the work they do, but actually admirable to do so. I know there are many people working in software who understand that their users, customers and organisations are a critical part of their environment. I know there are many who put their skills and abilities at the service of their customers, users, and companies, and make efforts to understand, participate in and influence the wider lives of their organisations. But I fear we are in the minority.
Great post about the underlying issue with any software improvement wave: what is the business impact? Why would any for-profit business care?
After all, top-quality software was never (up to now) co-related with success in the market place (the examples are too numerous to enumerate, but suffice it to say: Windows vs Unix-based systems).
There is a real danger of any “improvement” movement to become inbred and lost from the realities of business.
I’ve written in the past about this same danger: http://softwaredevelopmenttoday.blogspot.com/search?q=lets+fall+in+love
Thanks Vasco! On a related note, I’m indebted to Peter marks for the following quotation:
“Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets”
(Tom Stoppard, Artist Descending a Staircase)
While I agree that movements that turn inward tend to become irrelevant or even damaging I also know that all movements form splinters that turn inward. Certainly we see such splinters from the patterns and agile communities. But we also see that both communities have significant subgroups who have not fallen prey to this danger and who continue to contribute to our profession. I see no reason why the Software Craftsmanship movement should be any different. Indeed since Software Craftsmanship is expressly tied to customer partnership, I suspect the risk that major portions of the movement will turn inward is quite low.
Thanks for the post, David. It is good to talk this stuff through and consider the impact of the language we use to describe our approaches to software craftsmanship.
Can you provide some concrete examples of people actively ignoring the context of the work they do? Just like it’s tough to argue against craftsmanship, it’s definitely tough to argue for ignoring the context of your work. Who is advocating that?
I’m interested in why the word “apprentice” irritates you. I would like to hear more from you about that. Personally, I found the word “apprentice” incredibly useful when I first read Pete McBreen’s “Software Craftsmanship” back in 2002. Labels such as apprentice, journeyman, and master certainly aren’t going solve our problems, but, again, who is arguing that they will?
Bob, Dave, thanks for your replies.
Bob, I see no reason to believe that Software Craftsmanship should be less prone to evolving in the same way that any of the other waves that have (variously) rippled or crashed through the software world. That’s not to belittle the values, skills and commitment of those who pioneer these ideas and continue to develop them: it’s just (as I’m sure you’ll agree) that we’ve seen the way this goes all to often before. For example, it won’t be too long before there are too many books on Software Craftsmanship. It would be a pity if people thought (as I’m sure they will) that reading these is a substitute for reading Knuth, Dijkstra, Fowler, Beck, McConnell, SICP, GoF, Bentley, Meyer, Meyers, Martin :-) … and all the other truly great books, old and new, and many I’m sure to be written, that for me do a much better job of defining and inspiring our craft (small ‘C’).
Dave, I have no problem with the word or concept “apprentice”. It’s just when it’s tied up in an “apprentice, journeyman, master” progression that I have problems. I have an issue with anyone calling themselves master. And “journeyman”? If we want to be taken seriously as a profession, and as drivers of innovation in business and society, we have to stop inventing/re-discovering silly names to call ourselves. I also find the whole dojo/kata thing, with its overlay of martial arts and ninja wannabee-ism, unhelpful. It’s a long time since I’ve read it, but my memories of Pete McBreen’s book is that he does make a great deal of these labels. The words we use are much more important than we think in constructing our reality (check out Lakoff/Johnson’s “Metaphors We Live By”, and also the work on stereotypes and priming by John Bargh, to see just what a difference they make).
It sounds like you may have been lucky, but I’ve seen plenty of software groups (individuals, teams, and larger groups), usually in large organisations, chronically disconnected from the nature and purpose of those organisations (which btw is never just “profit” or “customer value”, but that’s a subject for another day). Maybe Software Craftsmanship will never touch these people, but maybe it will provide an excuse for not engaging with their colleagues, organisations, customers. I think the risk is worth pointing out: in the language and focus of SC I think there’s potential for more walls than bridges, and I worry that a burgeoning SC movement is in a sense a local optimisation that will distract us from the more systemic issues around software and product development, businesses, customers and markets.
I am not sure what is wrong with having distinction between different stages of a persons professional career? We are not equal throughout our career. Yes they are new words, we already have Junior, Consultant, Senior and Principle, but those are in many places completely useless and where they are not useless they mean something else then in Software Craftsmanship.
It is good to have different levels especially when teaching others, even if it was just because people in general will respect the opinion of a more senior person more than that of a peer (weird I know). Also one big difference in this and the general business world is that these terms are not about sales, should not be anyway.
I believe that craftsmen team can only exist in a company that does not use this to sell their recourses to clients, then that would mean that such company would only promote the idea that you should all be Masters and then we are not talking about Craftsmanship anymore. But a company that truly grasps this concept there management would not decide that you are a Journeyman or Master, peers would make such decision. And I believe this decision is mostly done for Journeyman where as being a Master is (I believe) more naturally, not from one dat to an other. It just is.
A Craftsman would not call himself a Journeyman or Master, his peers would call him that. It is not about getting this title, its about being a craftsman and when others consider you a Journeyman or Master it is because that is the role you naturally fulfill and its about the knowledge and experience you have. The different levels help asses the amount of guidance you may need and responsibility you can have, its not about being better.
Craftsmanship too me is among other things about teaching and being thought, it is about gaining more knowledge and practice in the craft you practice. I see no reason why someone believing in Craftsmanship would consider not reading those great books, on the contrary I would think it is more likely they read it, more then once. In fact I recommend people to read these and other books in the book that I am writing.
So even if you work in a company that does not support the idea of Craftsmen teams you can still consider yourself a Craftsman.
(of course these are my personal interpretations of Craftsmanship)
Before I was a software developer, I was a family therapist. I studied narrative therapy in graduate school, so I am keenly aware of the power that language has on our perceptions. The term “apprentice” was extremely helpful for me because it, via Pete’s book, gave me the direction I was lacking. When I hear you call “journeyman” a “silly name”, I feel like you don’t understand where I’m coming from… nor the many other people who find these labels, and the progression they describe, helpful.
To be clear, I don’t aspire to be taken seriously, or to be considered a driver of innovation. I aspire to be a great software developer. I aspire to create great software. If, in the process of achieving my aspirations, I am taken seriously, or considered an innovator, that’s great! But I don’t see how the labels I use to describe my progression relate to innovation or being taken seriously.
Since you find the dojo/kata thing unhelpful, I’m interested in hearing what you find helpful when you practice. For what it’s worth, I’ve always found building “breakable toys” more helpful for my practice than katas. (See: http://apprenticeship.oreilly.com/wiki/breakable_toys)
I have definitely been lucky in my journey as a software craftsman. But I’ve also consciously chosen to work for increasingly smaller organizations. Over the last year, as Software Craftsmanship has received more interest, it has been incredible to witness the number of bridges (not walls) being built. Small companies like 8th Light, Obtiva, and Relevance are swapping people to accelerate the spreading of knowledge and practices, and we’re open to expanding these swaps to companies many other companies, such as Eden and Hashrocket. People like Corey Haines have popularized the practice of visiting development shops, and now we have a constant stream of aspiring craftsmen in our Studio, working on their own projects and getting feedback from us.
It sounds like you’re worried about future walls. But I’m seeing present bridges.
Mark, there’s nothing wrong with having a distinction between different levels of experience. There are plenty of ways of doing this already, and (one of my) points is that the A-J-M terminology in itself creates the wrong impression (”primes a negative stereotype”, to use Bargh’s terms) and in doing so severs software development from the more interesting conversations going on in businesses nowadays. And as I repeatedly say, I’m not arguing with the notion of craft (small-c), skill, learning: I’m just pointing out the dangers of Software Craftsmanship (capital-both) becoming a “movement”.
Dave, thanks for the link - yes, that’s a nice way of looking at things. Personally I like the notion of _practice_ - both as a verb and as a noun - but also think we have plenty of language to describe the sort of working, teaching and learning collaborations that help foster individual and group learning (pairing, design workshop, scenario analysis, debugging session … ) Maybe there is a problem with people not having _processes_ to do these things effectively, and that’s the attraction of katas/dojos.
I’ve worked for and with organisations large, small, and all sizes between: the walls I see are often to do with larger organisations, and it’s not just a case of building future walls - the wall are already there. Software Craftsmanship doesn’t for me do anything about breaking down those walls in these organisations, and might even contribute to reinforcing them, but as yet this is just a fear.
“…a burgeoning SC movement is in a sense a local optimisation that will distract us from the more systemic issues around software and product development, businesses, customers and markets. ”
I think this perfectly crystallises some issues I’ve been struggling with at my current customer (a large multi-national bank). Lots of individual projects, each with strong technical TDD teams running CI builds and delivering every two weeks, with an apparently good relationship with their customers, and yet somehow the whole is so much less than the sum of the parts. And most of the time we try to fix the problem by improving the local process, because it’s simply too hard to change the organisation. SC - and agile too - say little about the relationship between multiple teams and the upper echelons of the customer organisation, and how you synchronise the beautifully agile small team with the lumbering beast of the large organisation and its market.