Category Archives: Software Craft

Software Craft

Some surveys on the state of our craft

One of my colleagues made a claim yesterday which I would like 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. :)

Continue reading “Say, how many books did you read this year?”

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.

Continue reading Some insights about TDD

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.

Continue reading Lessons from complexity thinking

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.

Continue reading Software Development Lessons from observing a movie team

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

 
 
Suggested by Ben Rady
“We follow our chosen practices?deliberately,?to ensure quality in our work”

 

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

What questions should be asked to a candidate to understand if he/she cares/understands what software craftsmanship is?
 
  • Do you follow a particular process to create your work?
  • What tools have you built to enhance your work?
  • When do you stop re-factoring and enhancing your code?
  • What are your training techniques?
  • How much time do you spend per week coding outside your main job?
  • How do you react when you discover a bug in your own software?
  • What are the first things you would teach a new apprentice?
  • How many languages do you know and can use consistently in the same project?
  • What are your most important influences in the programmers community?
  • Who is the best developer in the world in your opinion?
  • What makes you passionate about software?
  • Who else would call you a craftsman?
  • Do you consider your self involved with the software community?
  • Can you deliver consistent results in your code?
  • Can you define what good code is?
  • Can you point to some source code that you consider a masterpiece?
  • How do you react to something that you are forced to ship but is not consistent with your practices? (for example not tested?)
  • How do you stay current with industry standard?
  • Would you go back to a past customer project to fix your own bugs?
  • How do you define aesthetics and pragmatism in software?

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.

A week with Kent Beck

In November I had the opportunity to stay a whole week with Kent Beck. it-agile GmbH invited him for two courses – Responsive Design and Advanced TDD – and one workshop to Hamburg, Germany, and I took both courses and the workshop. Today I was contacted by Johannes Link who was surprised not to find a write-up of this week on my blog. It turns out somewhere during the past year I have turned into a reporter. So, here is my summary from what I could get from my notes. Initially I planned to write it via email to Johannes, but then I though why not share those comments on my blog. Maybe others are looking forward to it.

Continue reading A week with Kent Beck

Software Testing Apprentices

Yesterday, Jason Gorman called for action. He made his readers aware that the state of the art of software development is poor – dramatically poor. If we continue to work and educate the generations to come on software development, we are surely set up to continue to decline our craft even further than we did. Gorman explains the educational system to be tremendously poor for software programmers, that we won’t survive in a few years from now – assuming that Moore’s Law continues to apply. Read his full call to action in his blog post Time To Look Seriously At Software Developer Apprenticeships.

Some of the points look compelling to me, considering where I have come from, and where I consider to be heading towards. After dropping out of university in 2006 holding my German diploma in my hands, I got my first job shortly after my father had died of lunge cancer at the age 58. (I interviewed with my employer a few days before he died.) That said, I didn’t know a thing about software testing, never attended a software testing course – not that there was one, nor that I would have been interested in the topic at that time – back in university. Within the first two weeks I mostly sat down to read about the product they were building, intended to get some knowledge about it in my head from the large documentation.

But it simply didn’t stick. All the time I was asking myself, how this would turn out. I needed something to play around with. So, I got introduced to the shell scripts they had built to test the software part I should be working on. Within some week I was able to run some of these tests on my own. Shortly after that I was working on the project to extend the behavior. I excelled at it, pulling in work from other colleagues when I found myself finishing my assigned tasks before the assigned timeframe.

One year later, we were working for our first client. In the meantime I had taken over technical responsibility for the tests we were running for the customization that we built at that time. My boss’s boss called me into his office, and offered me to lead a group of five starting from one week from then. I had stayed one and a half year with that company at that time, and was offered a leadership position for some of their testers. I took the job.

Two months later I attended that first formal software testing training… and I found it rather boring.

That said, how do software testers start to learn about their craft? I don’t know how all of them learn about the craft of software testing, yet I know how I learned it. I read in the evenings, and at the breakfast table. I worked on my PC at home trying to get more knowledge about the area I was confronted with, trying to find out new ways to “test this”, immediately trying them out the next day. I was mentored by my superior, I mentored some of our new colleagues during the whole four and a half year that I worked with that company. I asked testers to build something, I explained underlying concepts, and helped them reach an understanding of what I consider software testing to be. I helped to make them grow as well. Having the same lack of formal training in software testing, I think this is what I would call apprenticeship, isn’t it?

I wasn’t all too sure about this up until earlier this week. Having taking a testing challenge from Matt Heusser in early 2009, I had become a black-belt tester in the Miagi-Do school, turning later into a black-belt instructor. Over the past year I have worked with three testers through a challenge, and helped two of them go beyond their current level of expertise and skill.

One of them was Michael Larsen, the TESTHEAD. By far he exceeded my own expectations. He worked through the black-box software testing course, became a mentor in this course on his own. He also worked at a local boyscout club as a boyscout leader. During the past year he has produced the weekly podcast on “This Week in Software Testing” together with Thomas Ponnet and Matt Heusser. He also first reviewed some of our draft chapters in a book on how to reduce the cost of testing. Later he turned in as a chapter author himself, taking the opportunity to contribute to something that is surely becoming meaningful.

Now, Michael just announced earlier this week, that he is going to switch jobs. He is currently running a blog series on how he prepares himself for the new job, and let’s everyone else participate in his learning. Reminds me largely on the apprenticeship blogs I saw from 8thLight apprentices, Eden apprentices, or ObjectMentor apprentices.

But the interesting thing about Michael is, that he got this new job by steadily working on his passion for testing, continuing to grow, and pushing himself to new limits. But you should definitely read his blog entry on how he got where he is.

That said, apprenticeships don’t seem to be a new idea for the software testing world. Lacking formal training, and disbelieving in the syllabus of the certification programs out there, software testers have built a high reputation based on their apprenticeship programs, and we know how to run them. We already do Software Craftsmanship to educate our peers. Let’s continue this, and intensify it even further. Maybe that could be a nice goal for 2011.