On the Software Craftsmanship conference in London End of February Micah Martin presented a session on where he presented an implementation of Langston’s Ant in Ruby. As an introduction he raised the point how important practice for a software craftsman is. He used his background in Martial Arts as a motivator where Katas are used to fit into uncomfortable positions in order to gain flexibility for the fight with an opponent. By over and over practicing these fight-unrelated moves, the aspirant learns for the fight. (Actually I remember the first Karate Kid film, where something alike happens, when the kid needs to paint a fence etc.)

By that time I did not fully agree to Micah’s point on practicing. However I made a note on my personal digest by then to research something suitable for me. Since I don’t have a background in Martial Arts, but in Swimming competition and as a swimming trainer, I was looking for analogies like how I teach kids to learn swimming with some learning chains getting from the easy to the complex and from the well-known to the unknown. These ideas did not quite match the Kata analogy from Micah, since they were related to how people learn in their minds and the bridge towards software development seems to be too far away here.

During the last week I found a better suitable analogy however, which is partially motivated from my experiences in swimming. As a trainer I need to be able to save anyone from drowning. While this sounds rather reasonable since I get to train kids that are entrusted to me by their parents, during the latest courses to fresh-up my knowledge on water-rescue I realzed, that the training for the german DLRG groups – the german baywatch – does over and over practice how to rescue someone from drowning. While the one being rescued might attempt to reach your neck in panic to just save herself, the life-saver might end up needing to save herself as well. While there are some grasps to free oneself out of such situations, the DLRG practices these over and over in order to be able to use them naturally when getting in a panic situation – since every second counts be then.

Similarly during first-aid courses which I needed to take several times as well I was told to practice reanimation process and how to get an injured person into recovery position. When people get under stress they forget what they have learned, if they did not practice over and over. Similarly when a software project gets under stress, people may forget to apply test-driven development, refactoring and design patterns and introduce technical debt. On the other hand by practicing seemingly unrelated software Katas in order to improve your tdd skills might enable you to excel your work even in serious situations. As for first-aid and water-rescue practicing, knowing and maintaining software development practices, but not having to use them every day, makes myself feel safer and relaxed.

Obtiva and 8th Light are currently stressing out Software Craftsmanship in an apprenticeship program between the two. Jim Suchy currently writes down experiences from each day on their blog. The entries for the first three days can be found here, here and here. While taking out the links for this entry, I also ran over Colin’s Apprenticeship.

As it turns out I ran into the idea two times during the last few weeks. One of our business analyst from our product development department stated some weeks ago that he has been asking for taking some kind of apprenticeship in the System Integration department in order to get to know the product he is defining. While the technical view of the product is rather clear to him, he stated that he is unsure of the actual use cases during System Integration work, where we configure most of the system for the end customer.

Some weeks earlier I ran over the idea as a tester to work on-site for your end customer in Lisa Crispin’s and Janet Gregory’s book. From the viewpoint of a tester I would be able to follow the mission to deliver working software to the customer in a better way when I had some experience on how the product will be used in the day-to-day work. By attending call-center calls and participating while our product is used to sell product to the end-consumers of our customers, I would get a very good picture of the business flow and the motivation behind it. Exactly what Gojko Adzic addresses in Bridging the Communication Gap.

Today I sat down with a former group lead in order to identify what I shall present on FIT end of next week. While we were discussing things I stated that two of my colleagues will be on vacational leave for four weeks during summer this year, since they will become fathers. While discussing the bottleneck in which we will get by then, he made the suggestion to exchange one of his testers with my group in order to get deeper knowledge on how we use FIT as a testing framework. Personally I think of it as an apprenticeship program, that could lead in improved communications between our two departments. Hopefully something great is going to be built out of this idea – but I’ll try to motivate and follow-up on this idea.

Today a friend of mine returned his computer that I repaired. While we stood outside and talked a bit about this and that, he told me about his job and his employee. He is a roofer and working in a craft. The interesting thing started when he told me, that he does not expect his employee to be hired for building new houses. This made me a bit sceptic, so I asked for the reason. He told me, that architects from new house projects do tenders for all kind of crafts, likewise for roofers. His boss does not participate in these tenders, because he knows that his estimates will be too expensive for new houses so he will not get involved in the project. Those companies that get involved on the other hand are lead by bosses that do price dumping in order to get the contract. Often these companies have roofers that need work on four new house projects during one week he said. It was really clear to him, that the quality of these roofers’ work suffers from these unrealistic assignments. He used the german word “Pfusch” to describe the level of quality of this work. In one or two years this roof will lead to mildew in the walls and all the like. Since new house projects don’t save money on the roofers but also on the other craftspersons, the result is likely to turn out awkward after some years. For a comparison he said that his company is happy with one roof over a week. He also mentioned, that his boss every now and then tries to do the same – push the people to make their job faster. They then ask the boss what does he expect from their work? Should they use just one instead of the usual five nails for each root tile knowing that their work will be of less quality? This is the point where the boss gets the insight, that it does not make sense to push for work being finished faster.

How does this relate to Software Craftsmanship? Take a step back and read the Manifesto for Software Craftsmanship now. There are four statements in it, similarly to the Agile Manifesto. Let me re-state these and raise my points here.

Not only working software, but also well-crafted software.

My friend, the roofer, knows that it does not make sense to deliver a roof that is working today, but is going to fail in one or two year. That is why he chooses to do his craft – roofing – properly and deliver his best result to the happy customer. Sure, it will be more expensive, but for good. Likewise delivering software that works today, may result in software that does not fulfill the quality needs of tomorrow. James Bach currently has a series on his blog, where he describes the quality creation myth in perfection. (Make sure to read the comments as well.) Quality is not built into our software, it is a time-effective reception of the product we built. This means it may be of good quality today, but might be of bad tomorrow if it fails to realize the new quality standards by then.

Not only responding to change, but also steadily adding value

My friend, the roofer, knows that it does not make sense to deliver a roof that is poured in iron and costs a lot to change its color. Who is going to buy these kind of roofs anyways? Supermarkets with a flat root maybe, but not a usual housekeeper. Likewise in software we must not think of requirements, design, code, tests as being carved in stone as well. We need to steadily deliver something that makes our customers happy. If I want to change my roof today, I can call a roofer and he does just this for me. Surely, this might take some time, according to his open contracts, the progress he is able to make, the wheather, but that roofer should know what I would like to get and that I might change my mind in two or three years. In most software projects I was involved in so far most people didn’t know what they did two hours from now. Without having an impressive set of unit tests they will even not get back into that knowledge quickly anymore.

Not only individuals and interactions, but also a community of professionals

My friend, the roofer, knows that he needs to collaborate with the community of roofers. He pretty much knows that it will pay off to visit a course in Berlin starting from summer to make his journeyman degree together with other community professionals. He knows that there is something he can learn from these other girls and guys, too. Likewise Coding Dojos, conferences and exchange in person or over the internet helps to build that community and exchange thoughts on different techniques. My friend the roofer knows that he has the opportunity to learn something for his whole life. I know this as well.

Not only customer collaboration, but also productive partnerships

My frined, the roofer, knows that by delivering a worthwhile roof today will get his boss into the position that today’s customer recommends his work to other stakeholders. That is why he chooses to push for the best job he can do today, even if this means to stretch the projects deadline. Maybe the recommendations from today’s customer will lead to new contracts for the next ten years. Likewise by producing the best software you can today (for some hints watch Robert Martin’s talk on Craftsmanship and Ethics), you may bring in contracts of tomorrow to your company. This may as well mean that you have to make a more expensive offering in terms of time or effort. But this time and effort pays off.

Skill

There is one more thing the roofer knows, but it is not mentioned in the manifesto explicitly. The roofer knows several techniques how to build a roof. There is one way or the other. He has a skillset of techniques that he can bring into each new project in order to help the customer get the roof they need. That is craft. Likewise a software craftsperson should have a skillset handy for each different project she might be involved in – and even those skills needed in other projects as well. I can’t tell you that you will never need Mock Objects, maybe you will, maybe you won’t. But knowing Mock Objects if you need them, is better than the other way round. This is the condome principle: Better to have one and don’t need it as to need one and don’t have it.