Do you think that the bar of professionalism has been raised in the 5 years since the Software Craftsmanship Manifesto was published? Why or why not?
My short answer is “yes” – and “no”. Being around since the early days back in November 2008 when I joined the Software Craftsmanship mailing list, and having been involved in the different thoughts on the Ethics of Software Craftsmanship, my longer answer hides in this blog entry.
A couple of weeks back, I became aware of a fact about electronic tools that gives a large drag to using it. I see lots of teams struggle with electronic tools. Most of the times these work with a raped bug-tracking tool used for – well, I think – status reporting towards their ScrumMaster during the daily Scrum meeting. That’s broken on so many levels – at least that’s what most team members reported to me when a particular tool was inflicted on them. The infliction usually happens either by sunken cost syndrome (“we invested XXXXX amount of money in that, you need to use it!”) or other self-imposed factors causes (“we work on twelve different planets”, “this paper thing is too touchy for me”, “we are green here, we don’t kill trees”). Let’s explore some of the reasons behind that, and try to come up with clues on why these are broken, and what I think the worst thing about these is.
When I became a swimming trainer, I had to learn various ways to teach kids how to improve their swimming strokes. As part of a seven weekend education course, we not only heard about stuff, but also had to give training lessons to our classmates that proved that we were eligible to the trainer certification. In these courses I learned about a gentle technique that I lately noticed to apply in other fields as well – whether appropriate or not.
I remember when Andreas Leidig approached me in late 2010. He wanted to get a discussion going regarding a conference on Software Craftsmanship in Germany. We decided to meet up during XP Days Germany in 2010, and see what we could do. We quickly agreed on an unconference format, two days, somewhere laid back. Some folks had organized the German Agile Coach Camp and Play4Agile in Rückersbach close to Frankfurt. We decided on that spot as well, and organized everything for 2011.
Early on, we decided that we will need outside support. That was when we started to reach out to other craftsmen, like Micah Martin, Adewale Oshineye, Sandro Mancuso, and many, many more. We had around 10-20 participants from outside Germany with us. All the tales they told us on how they were running things in London, Israel, Finland, you-name-it engaged us. It felt good to be around so many like-minded folks, and receive outside inspiration.
The first SoCraTes – Software Craftsmanship and Testing (un)conference – was a success. We had some track sessions back then, and a full day of Open Space. During the Open Space I joined a session that was looking for how to continue. With all the energy in the room, we placed ourselves on a virtual map of Germany. That was when I noticed, oh, there are a bunch of other folks around me that come from a similar location as I do. That was also when we decided that we needed to keep that spirit going.
One year later, we came back for SoCraTes 2012. Since the first conference we had founded 10 user groups all over Germany on Software Craftsmanship. There was one in Hamburg, one in Karlsruhe, one in Munich, one in Nürnberg, one in Berlin, one in Frankfurt, one in Dortmund, one in Düsseldorf, and one shared around Münster, Osnabrück, and Bielefeld. We created a timeline of events that had happened in the various local communities since our first get-together.
We were amazed about the various events, code retreats, user group meetings, and so on.
We still adhered to reserve space for foreign inspirations at that time. We had 10-20 people from outside Germany with us. However, Rückersbach had just 70 beds overall available. With ten local user groups potentially joining our unconference, we faced a serious problem. From each location just around 5 people would be able to join. So, with such a large community, we already excluded many potential attendees.
The format of the unconference had shifted. We had abandoned previously-set track sessions all-together. Instead we focused on two full days of Open Space. That provided the freedom necessary. Here’s the schedule from the two days in 2012.
At the end of the day, we decided to run the conference again in Rückersbach, but have it organized by a different group of people. We explicitly decided to pass over the organizing responsibility to one of the local groups from year to year.
Last year, the limited amount of beds became a problem. We discussed again what to do about it, and asked the organizers to seek a location that may scale up to 200 participants.
Rückersbach had an advantage: it was close to Frankfurt airport (about a one hour ride by car). That made it easy for people from other countries to attend, since Frankfurt is the largest airport in Germany. It would be hard to find such a spot with more beds in such a good position.
Late last year, the organizers contacted me. Since I am working in Hamburg, they asked me whether I could take a closer look at a potential spot for 2014 that sounded promising. They had 200 beds, and were located in Soltau. That’s about a one hour ride by car outside from Hamburg.
I agreed. When I finally made the trip there, I was amazed. The new hotel was awesome. There are ten meeting rooms all set up with video projectors, flipcharts, and so on, one central place where everyone meets, one large room for the Open Space opening, a bar with space for 170 people in the evening, a swimming pool, decent space outside close to nature. I got back to the organizers and told them that this spot would preserve the privacy that Rückersbach had with it, and that it seemed to be perfect to scale.
Now, I know that the announcement for SoCraTes 2014 is coming closer, and I can’t wait for the registration to open. Unfortunately I probably will only be able to attend on Friday, since I have a trip to the State to make for an AST board member meeting and CAST 2014 in the following week, but I know that I have to be there.
SoCraTes 2014 is scheduled for August 7th (evening arrival) to 9th, probably with a code retreat on Sunday, August 10th. I know it will be awesome. I know it will be full of craftsmanship, coding, and conferring. I know it will be worth my time. I now it will be worth the trip. You should reserve the date, too.
P.S.: Last week, I also heard rumors that the fine folks organizing SoCraTes 2014 are looking for sponsors. There will be different sponsor packages, some with free slots available. You can meet a bunch of fine folks there that are the top-notch in software development in Germany, Europe, and probably even the world. If you want to support the craft, please tell your bosses. It’s worth their money.
P.P.S.: Did you know that the UK folks – yeah, those that heavily influenced us in the first year – brought the same format to their country as well? I attended SoCraTes UK last year, and it was similarly awesome to the German event. They are organizing another event this year in June. Reserve the date as well.
A couple of days ago, Uncle Bob Martin blogged about the foreman in software development. In it he makes some claims with regards to a role in software development that acts like a foreman on a traditional construction site. Uncle Bob claims that the foreman should be the master of having commit rights, and granting those to team members that prevailed long enough. While the idea reminded me by-and-large to the practice on some open source projects, I am not so sure whether we should start installing foremen (and forewomen) all over the place. Let’s see why.
Agile methodologies favor effective team work. Team work is fun to do, hard to grow, and at times unpredictable to nurture. I might be biased here, but I have seen way too few good teams working effectively together. Let’s see what can happen with bad and with good team work in place.
Last week I sat in a meeting with a ProductOwner, a ScrumMaster, and the Development Team. The team works on a legacy code base with about 2 million lines of code together with 13 other teams. Thus far there has been little to decouple the various components. In that meeting the topic of refactoring came up. The bottom line was that the Development Team needed to ask the ProductOwner for time to refactor their code for each story.
What a waste of your time.
Personally, I believe that if you have to ask your ProductOwner to plan in time for refactoring, the ProductOwner should stop all work on the product, and send you on a class on working effectively with legacy code if you are an internal employee. If you are an external employee, your client should fire you immediately.
Wait, what? That’s harsh? I don’t think so.
Let’s take a look at the underlying system dynamics.
We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.