Craftsmanship in Corporate Software


The software craftsmanship movement is gaining momentum.  The idea that writing software is a craft is one that you may or may not agree with, but it is hard to disagree with some of the practices that the community promotes.  There are conferences and a manifest0 here that outlines the intent. 

So what practices are actually involved in the craftsmanship movement?  Opinions are somewhat divided but most people will point to this book as a good starting point.

It is easy to see this as a collection of the best and brightest in the industry promoting the next big thing, that can seem unattainable if you are working for a big corporate.  Deadlines, ‘heavy management’, ‘good enough thinking’ might be familiar friends.  Sure, the people of the cusp of this are notable ‘big thinkers’  but this movement has become more than this, and there are ways to bring this into to your organisation.

I am not going to give you a definition of the practices that I think make up a ‘craftsman’ but writing SOLID code is a great start.  But it’s more than that.  In my view a couple of key points are:-

  • Encourage a learning culture
  • Practice

Encourage a Learning Culture

This isn’t about building a skills matrix or sending people on courses.  This is about finding time to learn new things that could be brought into the workplace to make everyone better.  Building this culture takes time and effort.  Some / a few people need to lead it – note when I say lead I am not necessarily talking about managers.  I mean organise, facilitate, prepare.  This can be done by one / a small number of passionate people.

In my view, a learning culture means a supportive failure free environment.  I don’t want to get all tree-huggish here, but these are important concepts.   To me supportive means that people help each other learn.  This is not about one ‘expert’ that does all the teaching.  This will limit learning to the experience and expertise (not to mention bias) of that ‘expert.’   Supportive should mean that no-one is left behind.  If they don’t get ‘it’ then they are helped to understand.

Failure free is really about the idea that no question is too dumb, and no-one is wrong.  Think that something is a class not an interface great, lets have a discussion about it.  Don’t think that there is any value in TDD – let’s talk.  The most valuable insights can be gained from watching how other people do it or from disagreements.


If I am going to present a talk then I will practice speaking.  If I ever had to play an instrument in public (god forbid) then I would practice.  One of the tenets of craftsmanship is this idea that people should practice their craft.  So for us that means practicing code and everything related to coding outside of working on a product / project. 

How to do it?

Ok, this all sounds good, but how do we do it, and how much will it cost?  There are three things that I would start with., and none of them should cost any money.  Feel free to try one, two or all three depending on your organisation.

Communities of Interest

Form a community.  No really – do it.  Find a group of like minded people within your organisation.  Send out a mail to all developers about craftsmanship and see who responds.  Once you get off the ground others will join – I guarantee it.

Once you have some people who are keen to participate decide on what you want to achieve.  Want to be better devs?  Want to learn TDD, BDD, ATDD?  Want to understand and write SOLID code?   Once you have a community you can move on to..

Run a Coding Dojo

Huh?  A what?  A coding dojo is simply one way to achieve or practice a technique often using pair programming.  There are lots of links out there but I would recommend this one for TDD.  A good way to start is this. 

  • Define your goals – what are we trying to learn e.g. TDD.
  • Work out some rules for the Dojo.  Here are some example rules I have used in the past.

Coding challenge announced
Changes to pair every 10 mins
Everybody pairs
Stop when someone doesn’t get it
Design comments on green bar only
Do not add code if people are unhappy with design
Code in iterations

  • Define a backlog – the link above has a couple of great backlogs to get you started.  You could use these backlogs as a sample to build your own, or in place to use any technique – estimation / sizing, TDD, BDD etc.
  • Get Started!

I usually recommend doing a dojo at lunchtime.  Bring your lunch and code whilst eating.  This way it costs nothing.  I would definitely promote pairing as a great way to encourage shared learning.  There is nothing like watching other people code to learn new things.  If you have never paired before, who cares!  Give it a try.

Run a conference

An internal education event.  OK this one takes some money.  It costs time which means it costs money.  If the two things above have become successful then this can be a great next step.  I would start small, maybe a couple of hours one afternoon.  See if your management will give you that time (hey even if you make it up later)  Get a few keen people to give 30 min quick talks on things that they are passionate about.  It could be things that they have learning in dojos, or technologies that they code in at home.  What’s important is that they are passionate and keen to present.  I am sure that people who are not part of the community / dojos will want to attend.

If that is successful then do another one, until maybe you get a full day’s conference.  If management won’t give you the time then run it on a Saturday.  Trust me if people don’t want to  / won’t give up their Saturday then the craftsmanship movement is not for them.

Call to Action

Email your colleagues, start a community.  Try a dojo.  Take responsibility for your own development.  Trust me if you don’t no-one else will.

Looking to start  a craftsmanship community in your organisation?   Need some help?  Get in touch at


No comments :

Post a Comment