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.

Here is the wrap-up I wrote yesterday evening on the Software Craftsmanship conference in London while waiting for my plane to get me back home. I would like to thank Jason Gorman for organizing this conference. It was overwhelming and one of my favorite experiences so far. I also have to thank Gojko for his Specification Workshops talk. I’ll try them out. Micah Martin additionally made me aware that I need to practice with his Kata & Sparring session. You should read on the rest of the conference in the extended body.

Introduction

Jason Gorman invited to the first conference on Software Craftsmanship. Some weeks before the conference took place there was some ongoing discussion on the Software Craftsmanship google group on the definition of Software Craftsmanship and the distinction towards the Agile movement. Being a practical conference there were a lot of sessions focused on practices shown for the intended audience: Software Craftsmen.

Courses visited

Here are some brief insights based on my notes that I took during participating particular sessions. Before going into much detail on each session I will describe in brief what the session was all about before denoting my particular insights.

Mapping Personal Practices

Adewale Oshineye from Google presented very briefly two diagrams he created during similar workshops in the past and showed the audience two styles, that could be used. The goal was to build a mindmap structure of particular practices that were regularly applied from each of the participants. After that everyone had 10 minutes to write down her particular practices. After that an introduction round was started, where every participant should describe the contents of their mindmap to the remaining people in 90 seconds.

This technique was quite overwhelming. One question during the starting phase arose on how to focus the context of the map. Adewale had included technical and personal practices into his maps, so that this question was reasonable. The clue behind this technique is, that you can define the context and the focus as you may see fit. You can decide to just focus on technical practices or just on collaboration practices. Right before attending this session I already thought on trying to use this technique to see evolution points for the workers in my group and use it as a visual tool as well.
During the presentation of each participants’ map, I made some notes about what practices I apply but forgot to include in my map, what other practices sounded interesting and on what I would like to try out next. The list of interesting practices included E-Mails to oneself as a todo list, rather than wrapping up third-party frameworks build a more simpler solution on your own and using post-it notices to make the step from the short-term memory towards the long-term. One participant described that he first of all comes up with a name for a function and then deciding based on the name, on which class this new method should belong, as a design aid. Another participant described, that she likes to get some distance from the topic when striving with a hard problem. Getting some time to think over it can lead to a better solution in the end. Another one described that he regularly uses the revision history to get a clue of what happened to a particular class. There was also a call for help seekers, that do not argue their seek directly but rather indirectly instead. The one bringing up this item described that he had noticed that pattern and made himself aware of this. Traceability was also mentioned in that round. One participant described, that he regularly is asking stupid questions to resolve thinking abilities on his collaborators. The last thing I denoted on my list of interesting things is the ability of one participant’s customer to actually read the source code. While being able to have customers participate full-time on the project, this can lead to more direct customer conversation, if technical staff and customers are talking the same ubiquitous language.

Ruby Kata & Sparring

Micah Martin from 8th Light introduced the parallels between Martial Arts and Software development. He described, that during learning and practicing martial arts he was doing the same stuff over and over again; sometimes also for the sake to get better moving abilities during the fight by practicing movements that are actually not used in the fight itself. Micah concluded that the combination of practice, experiment and reflection leads to mastery in software development as well. After making his mission clear, he showed the audience an actual Kata he practiced over and over again. He showed the Langston’s Ant implemented in Ruby live.

Roughly in 10 minutes Micah used test-driven development to come up with a useable class, that could also be shown in a prepared evaluation program over several steps. After the session I got the opportunity to talk to Micah on his presentation. He stated that he had practiced solving the problem 30-40 times before. Since the solution just takes about 10 minutes to implement, he was also able to incorporate those sessions during daily work. The solution seemed very quick to me, even though not rushed. He ended up with roughly 20-30 lines of code and as much of unit test code as well. Since I saw his Kata I’m also planning to practice more small Katas in the next few weeks. Also I am thinking over to show some of these during a coding dojo session as a prepared Kata.

Specification Workshops

Gojko Adzic from Neuri gave a great talk on Specification Workshops, a technique he introduces in his latest book “Bridging the Communication Gap”. He introduced the session with an e-mail from an angry customer, where the customer described some business conditions with obvious inconsistencies. He then described the technique as a heading activation in each iteration right after picking the stories to implement in the next two to four weeks. Bringing together business people, developers and testers, discuss new stories in examples builds a shared understanding of the business among the relevant people in the project and helps building a common ubiquitous language.

Initially it seemed that there were just two people attending this session. Gojko nearly suggested to visit one of the sessions that were taking in parallel. Then a crowd of nearly 30 people came in, filling the room completely. There even were not enough charis for everyone to sit in there. During the talk I realized several concepts I just recently also read in other books. Gojko included in his reasoning the need to focus on the what and why during these sessions. The Poppendiecks describe this fact as set-based discussion rather than focusing on point-based negotiations. Developers and testers need to focus on what to implement rather than how and business people should be asked on the why’s behind proposed solutions in order to get an understanding of the underlying business problem and being able to cope with that. He introduced a story on printing from Java in the early days, which had troubled one of the projects he was on. After asking the customer why there had to be printing support in the software – which was rather complicated by that time – the team found out, that a re-arrangement of the UI navigation would make the need for printing support obsolete – and besides that more user friendly as well. The customer just kept asking for this since the company that had build the previous system was not able to re-arrange the UI flow. After the talk I had some words with Gojko. I am very pleased that he gave me a copy of his book “Bridging the Communication Gap” and I directly had to ask him to sign it for me. After reading the review comments from Lisa Crispin on it, I had already put it onto my order list on Amazon – now I can drop it from that list.

Gojko already put up the resources on his course on his blog. The slides should give you a good start on the topic.

Responsibility-driven Design with Mock Objects

Willem van den Ende and Marc Every from Quality Without A Name lead this session. Roughly they introduced the idea to use mock objects together with CRC card design in order to be able to directly incorporate the results from CRC design sessions into the software and unit-tests. In a rotational pairing session they also showed how to implement these for a text adventure game using rubyspec while including people from the audience.

Willem and Marc gave some guides before kicking off the demo session. On of the main goals with responsibility design is to avoid train wrecks, where a client of a class needs to call a function on one class getting another class, calling a function on that one, and so on, until the actual work happens. This distracts the reader of the source code and leads to high maintenance costs of software. One of the participants was obviously very familiar with responsibility-drive design since he gave several hints and remarked a lack of previous thinking during the live demo. The concept overall seemed to be very interesting, though the technique seems to be harder to learn.

Empirical Experiences of Refactoring in Open Source

Steve Counell from the Brunel University showed his empirical results from 7 open source software projects. He examined 15 refactorings for occurrence on these projects and had some very insightful graphs showing the usage and correlations to other refactorings and code-smells for the developers. Among the conclusions he gave were the tendency towards simpler refactorings, avoidance of encapsulation for the sake of testing purposes and interrelationships between i.e. move field and move method.

His graphs also showed that during the first few revisions of a class there were much more refactorings applied than to a later state. The conclusions from the code smells examination showed, that seemly easy code smells usually lead to a chain of up to 200 refactorings. Among these costly code smells were duplicate code and large class or large method. He closed with the tendency to not give in to seemingly easy smell removals, since they can very obviously pile up. In the discussion afterwards it was stated that there might be weight in the value coming from the costly smell removals as well. The overall study seemed very interesting to me. Maybe someone also comes up with a combination of version control, bug tracking and refactoring and examines their interrelationships. Steve also stated that the software they used for measuring the refactorings can be made available to other companies as well.

5 Reasons to have a Coding Dojo at your company

Ivan Sanchez lead this session. It was a quick introduction to Coding Dojos with some easy to follow-up rules. After that he asked for volunteers to a pairing session rotating each 5 minutes for a minesweeper implementation. Due to time-pressure he had already give it a head-start with some implementation to focus the overall on the experience rather than on 20 minute initial design decision. Ivan also enforced rules for the audience to just participate when there are green tests during the tdd-pairing session etc.

The session was very impressive and as a side effect I could get insights from the 20 favorite keyboard shortcuts session that I could not participate since it took place in parallel to Gojko’s session on Specification Workshops. (Alt-Shift-Up/Down is an impressive shortcut in eclipse – I’ll have to memorize this one.) During the last three weeks I already started some Coding Dojo sessions at work. What I got to know during this session was that I need to ensure the rules behind it more and force less discussion and more implementation after an initial discussion of 20 minutes.

Conclusion

During the next few months I will deepen Coding Dojos with my team and our developers. Among the practices that were new to me and I will definitely try out for some time are Specification Workshops and the Personal Practice Maps. Specification Workshops seemed to be a great opportunity since I realized just this week at work that there was some misunderstanding among some developers and the stakeholder of some functionality where these Specification Workshops would have helped. The Personal Practice Maps I will incorporate in April when I will have a evolution meeting with one my junior workers in order to get a better shared understanding of his particular personal practices and get him towards being journeyman. The Ruby Kata session made me excited on exercising TDD more in my leisure time. The session on responsibility-design made me curious about CRC card design. I think I will get a book on this as well. All together it was a great conference and 95% of the attendees raised the hand when Jason asked for visitors to the Software Craftsmanship Conference 2010. I’m looking forward to it, too.

Some thoughts on a manifesto based on the Agile Manifesto seems to be fostering. Doug Bradbury started a discussion on The New Left Side on the Software Craftsmanship Group. The list is currently in a sort of draft status, but it seems to be well thought-through already. Doug mentioned, that he has come up with an initial version some months ago. Personally I’m curious for more to come.