Today I crossed my review comments for the Apprenticeship Patterns which I wrote back in 2009. I wrote a blog entry back at that time about My long road. Reflecting back over the past – maybe – 3 years, I noticed something I wanted to write about: alternatives to apprenticeships – most of them I came across at my current employer it-agile. I remember that we discussed the topic of apprenticeships a few weeks ago at the local software craftsmanship user group meeting in Münster. We found that the apprenticeship model does not fit well into Germany’s working model in the IT industry. So, we tried to come up with alternatives. Here are the ones I have seen implemented at different companies: Mentoring and Peer-Groups.
Category Archives: Software Craftsmanship
Responses from the programmer and tester surveys
A while ago, I called for some participation on the state of our craft. I promised back then to present some intermediate answers in late January. Here they are.
8 things you ought to know if you do not know anything about hiring a software tester
In a recent blog entry over at 8thLight’s blog Angelique Martin points out to 8 things you ought to know if you do not know anything about hiring a software developer. Having been involved with the Software Craftsmanship movement since the early days, and 8thLight has played a major role in that movement early on, this list was compelling to me.
In short, Angelique reminds us to ask potential new employees for the development processes they used, their development practices, – particularly TDD, pair programming, short iterations, and continuous integration – and how they educated themselves and kept their claws sharp. She also points out that she would ask for a proof of their talent, how they estimated, how deadlines are met, and what they can say about the costs involved when developing software.
This list was so compelling to that I decided to put up a similar list with the things I was looking out for hiring a software tester. I believe there are some unique skills I would look for in a software tester that I would not necessarily look for in a programmer. So, here it is.
Some surveys on the state of our craft
One of my colleagues made a claim yesterday which I would viagra to put some numbers on. I raised the question on twitter, and received suspicious answers about the numbers of my colleague. Please forward this survey to anyone you know who is programming: http://www.shino.de/programmer-survey/ It consist of just four question, so you should be able to answer them in a few minutes.
Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.
From time to time to I will publish some of the results. I aim for end of January for the first set of data.
“Say, how many books did you read this year?”
At the beginning of November I attended a conference together with my boss Henning Wolf. While flying back to Hamburg, waiting for our plane, we talked about things, and I mentioned some lessons from a book that I was reading at that time. “Say, how many books do you read within a year?” he asked. I couldn’t answer that question directly, as keeping in mind that this was my seventeenth book would distract me from reading the content. So, I looked it up, and was amazed.
I am sure, I do not exceed the number of books that for example Michael Larsen read this year, but I was still amazed about the number – having estimated it at about ten or twelve. I decided to visit back the books I read, and see which lessons stayed current even after having read them. This list is based upon my notes over at Library Thing, where I looked up which books I finished this year. Some of them I started back in 2010. Some of them are also in German. some have an English translation, others don’t. Maybe time learning some German for some of my readers. :)
Some insights about TDD
At the recent meeting of Hamburg’s Softwerkskammer – the German Software Craftsmanship movement – we worked through a Coding Dojo on the Roman Numeral Kata. Michael Norton wrote today about one piece that worried me as well. I think Michael did a fantastic job on tackling a different approach. But he reminded me that I wanted to put up some of the thoughts from the Coding Dojo.
We had about 12 participants in the dojo. After explaining some pieces about the format and the kata, we started the dojo. As the kata started, we had one participant asking questions up to the degree that the pair in front of the keyboard stopped doing anything.
Eventually we got the team back up to continue working on the problem. The claim of the interrupter was that we didn’t yet understand the problem well enough to design the solution. Another claim was that TDD was not a design technique. Let’s take a closer look at both of these.
Lessons from complexity thinking
While Diana Larsen was in Germany in July she spoke about a course she was currently taking called Human Systems Dynamics. Since then some of my colleagues started to dive into it. So did I. I didn’t take the course, but decided to go for some of the books on it. The first one I came across is called Facilitating Organization Change – Lessons from complexity science, and deals with a lot of stuff on complexity science, self-organization, and how to introduce changes in a complex adaptive system (CAS). These are some of my first thoughts after finishing the book.
Software Development Lessons from observing a movie team
A while back I was part of a team that made a small advertisement movie. We planned this back in June, and finally made the shots in early September on a single day. There were quite some lessons I learned from them, and how they worked. Even though I didn’t get to work with Steven Spielberg, I was still able to see parallels in the movie profession to my life as a software tester and software developer. Time to reflect on that.
Software Craftsmanship is real in Germany
You know what happened on the March 7th 2009? According to Wikipedia, the Real Irish Republican Army killed two British soldiers and two civilians, the first British military deaths in Northern Ireland since The Troubles, and the Kepler space observatory, designed to discover Earth-like planets orbiting other stars, was launched. Right. But there was also something happening in the software development sphere. You don’t remember? The Software Craftsmanship Manifesto went public. Amazing.
Paul Pagel announced the publication on the Software Craftsmanship mailing list using the following words:
Craftsmen,
In December, many of us met in Libertyville at the first ‘craftsmanship summit’ with the intent of establishing a set of principles for Software Craftsmanship. After the summit, the conversations continued on the mailing list, finally culminating in an elegant summarization of our thoughts by Doug Bradbury. Today, we put the manifesto up on the web as a statement of our values as craftsmen. I’m inviting you, as members of the software craftsmen community, to view the manifesto and, if you choose, to sign it.
http://manifesto.softwarecraftsmanship.org/
This is an exciting time for all of us, a result of the participation and thoughts of everyone, both at the summit and in the subsequent discussion online. I want to thank everyone for carrying these ideas forward.
Best,
Paul Pagel
About one week later, Mark Levison had interviewed some of the folks who were involved in the early days of the movement, among them was Micah Martin who found the right words when he saw that 1500 people already had signed the manifesto after just one week:
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.
That quote immediately sprang to my mind last Saturday when I head home from the first German Socftware Craftsmanship and Testing (un)conference. With 52 participants from at least five different countries, we had 52 people getting together in order to carry on that message, in order to fight crappy code.
No wonder then, that we had a lot of coding sessions. Sandro Mancuso for example led through a session using the Nine Rules from Jeff Bay’s Stefan Roock led through several coding dojos on the OpenSpace day.
But beyond that, I was glad to see other topics that are sometimes forgotten when speaking about craftsmanship. In fact, if you take a closer look on the manifesto, it states that we want to raise the bar by growing communities, and helping others learn what we do, and how we do it. That said, there was a talk by Fabian Lange on performance, one by Uwe Friedrichsen on architecture, one by Pierluigi Pugliese on soft skills for developers, and my session on self-education in testing. We also got together in a fishbowl on software craftsmanship in order to seek opportunities to go further from the starting point of SoCraTes, and grow communities all over the country. We had Uri Lavi who leads the user groups in Isreal as well as Sandro Mancuso who runs the London Software Craftsmanship user group.
In a call to action on Saturday we decided who was interested in running a meet-ups in the next two months in different locations all over Germany. Just in case you live nearby Hamrbug, Osnabrück, Münster, Bielefeld, Düsseldorf, Köln, Karlsruhe, and Frankfurt keep your eyes and ears open. There’s probably soon someone starting something, announcing something, or just getting together in a bar to discuss the topic of Software Craftsmanship, and what it means to us.
I was really impressed. Not only having been around in those early days on the Software Craftsmanship mailing list back in December 2008 when it all started, but also being in the loop of discussions around the Ethics of Software Craftsmanship, having contributed to the Wandering book, and having helped organizing this event (please send the real kudos to Andreas Leidig and Nicole Rauch who mostly put together this conference alongside Bernhard Findeis, Martin Klose, Marc Phillip and myself), it was so amazing seeing this become real, and kicking off for next actions to grow a community in Germany.
I look forward for more to come after this inaugural get-together of the German Craftsmanship community, and will surely report on the things that are going to happen.
Some Software Craftsmanship treasures
While reviewing some proposals for the SoCraTes (un)conference, the German Software Craftsmanship and Testing conference, I wanted to look something up in the principles statements that we came up with back in 2009 shortly after writing down the manifesto. Unfortunately I found out that Google Groups is going to turn down files and pages inside groups, and you can just download the latest versions of the files and pages now.
After downloading them, I found some treasures, which I would like to keep – even after Google took down the pages section in their groups. So, here it is.
Software Craftsmanship Ethics
I was involved in the discussion that came up to identify the principle statements similar to the Agile manifesto and principles there. It was Doug Bradbury from 8thLight who constantly tracked what the other twelve people on the mail thread were replying, and derived something meaningful out of it in the end. I don’t recall why these principles – which we later called the ethics – were never published on the manifesto page, but I think it had something to do with the discussion on the mailing list after we announced the final draft for discussion. (I obviously didn’t take the time to follow that discussion. There were too many replies for me to keep track.) So, here is the final version. Interestingly we saw the four main categories also in the four statements of the manifesto.
The Software Craftsman’s Ethic
***DRAFT*****
We Care
We consider it our responsibility
to gain the trust of the businesses we serve;
therefore, we
take our customer’s problems as seriously as they do and
stake our reputation on the quality of the work we produce.
We Practice
We consider it our responsibility
to write code that is defect-free, proven, readable, understandable and malleable;
therefore, we
follow our chosen practices meticulously even under pressure and
practice our techniques regularly.
We Learn
We consider it our responsibility
to hone our craft in pursuit of mastery;
therefore, we
continuously explore new technologies and
read and study the work of other craftsmen.
We Share
We consider it our responsibility
to perpetuate the craft of Software;
therefore, we
enlist apprentices to learn it and
actively engage other craftsmen in dialogue and practice.
Original Software Craftsmanship Charter
In the early days we were struggling on how to get started. Back in November and December 2008 we collected together some statements from the books that we felt strong about. In the archive, this is kept as the original Software Craftsmanship charter. Later some of these statements were turned in for the manifesto and the principles. You can already see the structure of the final manifesto in there, but it’s still merely a brainstorming list. Here is the version from the google groups pages:
Original Software Craftsmanship Charter
Raising the Bar
As an aspiring craftsman/professional,
… we can say no– Do no harm
… we can work in a way we can take pride in.
… we take responsibility for the code we write
… we believe the code is also an end, not just a means.
… we follow a strict set of practices and disciplines that ensure the quality in our work
… we live and work in a community with other craftsmen
… we will help other craftsmen in their journey
… are proud of my portfolio of successful projects
… can? point to the people who mentored me and who I mentored
Here are some of my suggestions: (DougB)
As aspiring Software Craftsmen we are raising the bar of professional software development.
??? We are proud of our work and the manner of our work
??? We follow a set of practices and disciplines that ensure quality in our work
??? We take responsibility for the code we write
??? We live and work in a community with other craftsmen
??? We are proud of our portfolio of successful projects
??? We can point to the people who influenced us and who we influenced
??? We believe the code is also an end, not just a means.
??? We say no to prevent doing harm to our craft
My suggestions: (Matt Heusser)
? We take responsibility for the code we write ++
? We take responsibility for our own personal software process(*)
? We take responsibility for the outcome of the process
???? That is to say, a laborer delivers software on specification
???? A craftsman develops a solution to an interesting and ambiguous problem in a way that delights the customer
(*) – not the one owned by Watts Humphries
List of questions
Someone (I forgot who) mentioned a list of interview questions from the 8thLight office. They held some of the inaugural software craftsmanship user group meeting back in December 2008 there in Chicago, and eventually crafted together a basis for the manifesto. One of the attendee wrote down some interview questions which were floating around there. Here is the list:
List of Questions
Final words
So, having put these artifacts from the early days of software craftsmanship on my blog, I hope they won’t get lost. I still hope that the ethics statements we came up with will make it to the manifesto page one day, but until then I can reference this blog entry.