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.

In the last few weeks I have not taken the time to follow-up on the series I started some weeks ago. In the meantime Lisa Crispin had an entry on ten principles for Agile testers as described by Jeff Langr and Tim Ottinger. Since I took some of the principles from Lisa and Janet, you will find these as well on my list as well – though I recommend buying the book anyways.

• Respond to Change

Responding to change is critical in most software businesses. Customer requirements keep changing. Therefore the most valueable needs to be able to cope with that change as well. As a tester it is therefore counter-productive to act as a gatekepper with a conservative view towards change. Bach, Kaner and Pettichord were the first I read this about, though the underlying thinking clearly is not new. As testers we need to be able to respond to changes demanded be the business as well as changes demanded by technical constraints such as the programming language of the system under test or test automation tools. Insights from Refactoring and Design Principles such as the SOLID principles from Robert Martin are tools of knowledge that can help to adapt tests to the chaning business. As pointed out by Robert Martin

Knowledge of the principles and patterns gives you the justification to decide when and where to apply them. If you don’t know them, your decisions are much more arbitrary.

This applies to developers as well as to software testers.

• Self-Organize

Without self-organization testing becomes a tedious task. If your work is organized from someone else, your testing tasks become a job of a assembly-line worker and you could be replaced by the next student looking for a job. This might seem a hard statement and I’m exaggerating to some degree, but if a tester does not organize herself, then why not replace her with a cheaper student? As highly educated professionals we have to take care to do a good job and defend our position on what is to be done in order to work on the project at hand. This may mean to write a big test plan up-front, this may mean to find the proper amount of automated and exploratory tests or this may mean to bring together business people, developers and testers in order to improve communications. Of course our decisions are sometimes wrong on these items. In that case we need to be human enough to learn from our failures in this case in order to improve.

Probably the most common violence of self-organization lies in the fact, that most testers are waiting for something to be delivered to them. Even ten years after defining test-driven development and the Agile movement this is the case. Robert Martin raised the point of Never be blocked during his talk on Craftsmanship and Ethics from the JAOO Conference. The need to wait for something to be delivered means that you’re blocked. Prevent these situations by finding ways to work together with your developer. Maybe you will find that there is a vast amount of unit tests for your particular business rule and these are regularly run. Maybe you can improve the code before it gets to you. You need self-organization to see these opportunities and decide whether to take the next story or improve the software at the instance it is written.

• Focus on People

Regularly testers on traditional style projects complain about getting source code just thrown over the wall. While agile methodologies focus on the whole team participating in testing, the more general principle behind this is the focus on people. Testers not getting out of their cubicles in order to talk to developers, management and stakeholders cannot expect to get involved early in the development cycle. Did you ever try to talk to your lead designer before firing that blocking bug into the bug tracking system? When did you ask your customer about that edge case left out during specification gathering the last time? By letting the people around you on the project decide what to do in the situation at hand, you might be invited to the specifcation workshop the next time. Matt Heusser described this moment as How to be a first-class citizen as tester. Just when you have the intuition that something is broken and can show this to your stakeholders, you’re going to get invited to the elephants’ meetings afterwards – maybe. Focussing on people is the more general principle behind this and may get you on the road to the first-class citizen in your company.

• Enjoy

Based on my previous work experiences – not just in the software world – enjoyment matters most. An unhappy tester that just gets flooded by over-the-wall-thrown code is unlikely to deliver back value to the project. If the testers are filled with pride in their work, they will even enjoy their work and become an essential part of the project team. Some weeks ago I took a voluntary session with Michael Bolton. Michael had selected an exercise from his courses on Rapid Software Testing. We had timeframed our session previously to one hour, but ended up at 1.5 to 2 hours. We overdraw the session, but I did not feel to comply about it. I experienced so much enjoyment during the session, that I wanted to share this experience with my peers immediately. One week later I did. And they felt the same. While enjoyment cannot be mandated by a manager or corporation lead, if you’re in the situation to enjoy your work, your giving it a better care – which improves your enjoyment as well. Enjoyment prevents us from taken the next job opportunity, from becoming a developer, etc. Taking in the joy into our work helps to have pride in it. You shouldn’t live without it.

• Testing moves the project forward

Some months ago Cem Kaner wrote a rather long chain of replies on the Software Testing group on an article by Lisa Crispin and Janet Gregory that reminded me on this principle in Lessons Learned in Software Testing. One of the key points that Agile methodologies showed us is that tests really drive the development effort forward.

Test-driven development is more considered a design technique as a testing technique. Similarly Gojko Adzic redefined Agile Acceptance Tests as Executable Requirements in his book Bridging the Communication Gap. Both practices have somehow their roots back about 50 years in time, as I got to know by a blog entry from Jerry Weinberg. They all three have in common that these techniques have been motivated initially by testing needs. These are examples where testing moved the software development process forward and the same holds for each project as well.

• Testing is not a phase

In order to take proper effect, testing needs to be a continuous action. When testing is handled in a phase after the fact – after the software has been built- then all the made up assumptions during the earlier phases – like requirements, concept, design and code – sum up into one single point: the tester behind the wall. Have you ever wondered, how come you’re testers need so much more time than you to code? Fred Brooks wrote in The Mythical Man-Month that just a tiny piece of the time spent in a project is taking for actually writing the code. Requirements, concepts and designs give developers a good starting point on the business terms in the project. In order for testers to do their job well they also need to have this knowledge right from the start. By just giving them the code and the 500 pages of documentation, you’re not only treatening them as lessers, but also making their time spent on projects a hard deal.

On the other hand quality in software is not built, as James Bach lately pointed out. All practices during the development of the software need to ensure that the quality in it is kept alive. Testers and testing in general cannot bring back a dead body of quality in your product, if it’s decomposing there for months already.

• Everybody tests not just the designated testers

After the last principle this should be obvious. The whole team is responsible for having the product tested. Every code review, Pair Programming session, Iteration Demo, Specification Workshop etc. enables the whole team to participate in testing the product. Since everyone on a deveopment knows a tiny of the software, getting everything together in form of an executable specification of the product enables the team to deliver business value from the start. If everybody is part of the testing that’s happening, the Broken Windows Effect is minimised and bugs don’t start to pile up.

• Reduce feedback latency

Feedback is a core value in nearly all Agile methodlogies. Recently Robert Martin gave a key talk on Craftsmanship and Ethics where he pointed this out while referring to unit tests and code coverage.

Have ever looked on a function you implemented two hours ago and thought: “Oh my god, what’s this doing?”

Feedback latency is essential for testing. Just quick feedback on a broken build, damaged customer value and technical debt gives you the opportunity to learn from it. If two weeks of development passed by, you’re most likely to have lost the red line in the code. This is why feedback needs to provided immediately.

• Tests represent expectations

When dealing with Specification Workshops or in Acceptance Test-driven development the team defines together with the customer representative how the system should behave after the agreed on functionality is implemented. Test frameworks as FitNesse or Concordion shorten the gap between these examples or expectations and the tests used in order to drive your development forward. By being able to directly use the output from your requirements, you’re able to product the right code. Similarly unit tests focus more on producing the code in the right manner. Therefore they reflect more the design expectation in your development efforts. It should be obvious that you cannot live without one or the other.

• Tested is part of “Done”

A feature or story is just defined as being done, when it’s really tested. The feature is not production-ready when the developer has finished the coding for it. Instead it is finished when everything is in place to get the tests passing, the acceptance from the customer in the iteration demo and thereby the production ready configuration of the parts. Everything else is scaffolding and should be avoided completely. Particularly does scaffolding in the software business lead to higher maintenance costs for features that had not brought in any money. Just tested, production-ready software enables your company to earn money from your work.

Considering different your daily work, the motivation for team members will also change. Instead of sub-optimizing towards “but I’m finished” mentality, definining “Done” as “Tested” enables developers to look over their wall and see if the brick they just throw did any hurt. By moving the measurement on level up from “coded” to “tested”, there is call for all team members to focus on just this bit rather than sub-optimizing just their building lot. The project and the team is not finished with a particular piece of functionality, if the customer cannot use it – period. This is reflected in this principle.

Micah Martin just gave a personal answer to an upcoming article on InfoQ on the Software Craftsmanship Manifesto, that was put into public this weekend.

2) How will it help solve the problems of crap code?

As of today, there are over 1500 signatures on the Manifesto. 1500
people are fighting against “crap code”. Those who have been fighting
“crap code” now know that they are not alone in their fight. Those
who write “crap code” now know that there are 1500 people fighting
against them.

The Manifesto is a gentle push away from “crap code” and toward
craftsmanship.

Personally I would like to make some posters with this statement printed on it and hang them out in public at work. Maybe someone can come up with an information radiator, which is updating the number of “crap code fighters” as anyone new signs it.

Doug Bradbury and Paul Hagel compiled together the Software Craftsmanshup Manifesto. The Manifesto is based on an initial summit in Libertyville in December 2008. After that summit, the output was discussed over the last two months on the Software Craftsmanship Googlegroup resulting in a distinguishing list of values similar to the Agile Manifesto.

I had to immediately sign this manifesto, since I couldn’t agree more to it. Over the past one to two years I have seen crappy software built under higher management constraints lacking basic quality. Taking Jerry Weinberg’s quote “Quality is value to some person.”, I don’t see much value in most of the software I have to deal with on a daily basis. James Bach seems to have a similar view on the things. That caused him start a series on the death of quality this week; just 24 hours later he explored together with Michael Bolton a software project, which claims to deploy 50 times a day resulting in poorly received quality – at least for James and Michael.

Currently I’m hoping that craftsmanship thinking can bring the software development business back on track. Personally I would like to write code to be proud of and don’t have a bad feeling about that one class, where I screwed up. As a software craftsman I appreciate the work of others around the globe in the field and I’m very glad to exchange thoughts on their work and my work at conferences or via online tools such as instant messaging or desktop sharing. Just this week I had the opportunity to exchange some thoughts with Michael Bolton and I experienced a very nice contact in it. Michael had the ability to make me think on many things, that I have already read about – 2 years ago – but forgot to include into my daily work life so far. Just one week ago I had the other opportunity to meet Gojko Adzic at the Software Craftsmanship Conference in London. One year ago I started to give Lisa Crispin and Janet Gregory feedback on their book on Agile Testing. I’m sure I could perpetuate this list even more, but personally I would like to stick to the most meaningful contacts from the last year for now.

Maybe poor received quality has become a linear feature in our software systems. Maybe most of the people out there think this is ok. This is where I personally heavily disagree. Being a perfectionist to some degree I would like to see software that delights myself, where I say “why hasn’t this product been developed in this case long ago?”. From my point of view this distinguishes mass-market software from well-crafted software.