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.