The 13th and Final Week

The 13th week of my Pair Programming tour started a bit uncertain. I had not been able to finish the arrangement with the company I had planned to visit. I had got positive replies from my contact there that his team was interested and that he would ask the HR department for final approval. And then there was only silence ;-) Additionally winter came to Austria and the temperature fell by ten degrees just over night. I was exhausted and thought about quitting the tour prematurely.

But then, in the beginning of the week, the first FirefoxOS DevTreff meetup in Austria took place and I met some really enthusiastic hackers who immediately agreed to host me. So I went on with my tour for another week. First I visited a development team to run some in-house training. Besides the usual Coding Dojo we wanted to try something different this time. We started refactoring some nasty piece of production code Randori-style. It was really interesting to see the whole team communicating, e.g. the architect was surprised to see certain patterns in the class we worked on. Everybody was engaged and I wanted to encourage everybody to contribute so I abandoned the Randori-dojo protocol and the session turned into Mob Programming. It was fascinating. In the end the team agreed to use this style of working for our next session as well.

Déjà vu
Then I visited Jürgen Cito in his office at the University of Technology, Vienna. I had a strong sensation of Déjà vu because many years ago, I had roamed these very same rooms in the beginning of my own studies. Jürgen told me about his master thesis about Statistical Methods in Managing Web Performance. It looked great and I am looking forward to the finished work. He had finished his research and was just wrapping things up so there was little we could work on. Instead Jürgen told me about an idea he had for some time and so we created Sinatramania. Sinatramania compares (or rather will compare) the different frameworks based on the Ruby Framework Sinatra by implementing the same simple REST API in the different programming languages and frameworks. We created a Cucumber test suite and started with the Sinatra reference implementation. It was much fun and I will definitely send him some pull requests as soon as things settle down. If you use one framework inspired by Sinatra, e.g. Flask, Laravel, Ratpack or Scalatra, then I encourage you to add your implementation to Sinatramania.

Tying up loose ends
I started my tour visiting the Vienna Ruby Community, presenting them my idea of Journeyman Tour. Back then the leaders of the group had invited me to run a Coding Dojo but it had taken almost three months to find a suitable date while I was busy on tour. Finally I came back to deliver the promised Ruby Coding Dojo. We worked on the String Calculator Kata, a perfect exercise for a first time Dojo. We had excellent discussions and I particularly liked Ben's question if three powerful Ruby functions like split, map and reduce might be too much to squeeze into a single line of code. Yes, with great power comes great responsibility ;-)


Friday I visited an old friend. His line manager had agreed to my visit but he had not bothered to ask for full, official approval up the hierarchy. So I cannot name him nor his employer. Nevertheless it was a great day. In the morning we discussed TDD and integration tests. Then we created a new Maven plugin, test first of course. I proposed to create a guiding test, which we built using the Maven Invoker Plugin. It took us half of a day to get the guiding test ready, because asserting the proper behaviour of our plugin under test was tricky. I learned a lot and Maven Invoker looked like a good alternative for the Maven Plugin Testing Tools, especially when considering the problems I had with them. Using the guiding test, further development was smooth and we would have finished the plugin on the second day. I was really sad that we only had one day to work on it.

This is the end my only friend, the end
As the title of this blog post implied, this was the last week of my tour and it ends my diary. You ask me why? You say that my tour sounds like some serious fun and I should go on forever. Actually I cannot. First I need a break. Second I ran out of companies. I wrote earlier that it took me roughly a man-month (160 hours) to find the 16 companies that hosted me and during my tour I did not have time to look for new hosts. Further I had planned my tour to last for three months and it had been exactly three months. Finally I need to go back to work and earn some money again. Although lunch was free, I spent a lot of money on commuting. Although my tour has ended, I still have many things I want to share. I will discuss what I have learned in upcoming posts, so stay tuned.

A Dozen Weeks

Gilded Rose, again
In the 12th week of my Software Craftsmanship tour I ran an in-house Coding Dojo for a team that wanted to improve their unit testing skills. After an introduction what constitutes (and what does not) a good unit test I wanted them to practice. Understanding the concept of unit tests and using the corresponding testing framework was no big deal, but applying all the principles in practice was harder than it looked. I asked them to write the Test Cases for the Gilded Rose Kata, an exercise designed by Emily Bache. Since I participated in Emily's session during this year's XP conference in Vienna, I just love this kata. Although creating test cases for a small piece of logic might seem trivial, there is so much one can learn here. I had run the same kata during one of my Dojos at Agile Testing Days before and got a lot of positive feedback. If you got curious about the kata, it is described in full detail in Emily's excellent Coding Dojo Handbook.

Quality important is. Fight for it you must ;-)
Next I visited Gregor Riegler. I had not known Gregor before my tour, but his blog Be a Better Developer had attracted my attention. I really liked its subtitle "Quality important is". When I studied his blog I noticed that he was from Austria, even Vienna. I immediately sent him an email and Gregor was interested in my tour right away. Although it looked like we would not be able to pair, he managed to get approval from his management in the end. I spent three days in the office of EBCONT enterprise technologies, in the 34th floor of the Millennium City and enjoyed the view.

Gregor called himself a Restifarian and so we rightfully worked on a REST API for his current project. The Spring Web-MVC powered REST resources would just display data from the database, and first it looked that there would be no particular logic to put into the resource controllers. But we needed links to related resources, the so called hypertext. We had great discussions how to create and add these links to the response in a DRY way without messing up the domain model which we wanted to stay independent of any technology. I liked our session very much and learned a lot both about REST and learning in general. Thank you Gregor!

November is DemoCamp Time
Since the very first Eclipse DemoCamp in Vienna, November 30th 2009, we kept up the tradition of organizing an Eclipse DemoCamp twice a year. So Friday afternoon was demo time. For the ninth time the Vienna Eclipse enthusiasts met to see all the cool technology being built by the Eclipse community. There were great presentations by Tom Schindl, Gunnar Wagenknecht and Benjamin Cabé as well as some local people. The closing presentation was Flo's famous demo remote controlling Sharky. It was a pleasant event and socialising continued till late night. You should definitely attend our next DemoCamp in June. To keep updated about it, follow us on Twitter: @edcvienna. (Please note that the Twitter handle was changed recently.)

CodeCopTour Week 11

In the eleventh week of my Software Craftsmanship tour I visited the Austrian Lotteries gaming enterprise. I paired with Felix Kammerer and Stanka Gasic from the development team only one day each. In these days I learned that I am a keyboard hugger ;-) Usually I am dominating my pair. The situation is better if there is no second keyboard because it takes more energy to take it away actively from my pair than to just start typing on my own one. Maybe I will continue my tour without an extra keyboard from now on...

Devoxx 2013
The manager of the Lotteries' development department had invited me for a longer visit, and I had planned my tour accordingly, but I had to change my plans on short notice. In a last-minute lottery the Vienna Scala User Group gave away a ticket for this year's Devoxx conference in Antwerp, Belgium. I have been to Devoxx before and it really is a great conference. I had not planned for it because I knew that I would be busy with my tour, but obviously I was supposed to go there after all. Luckily my JUG voucher was still valid after the conference had been sold out, which usually happens quite early. On my return I gave a short presentation at the Scala Vienna meetup about my impressions of Devoxx 2013. The short summary is that Devoxx is a great conference and you need to go there, at least once. I probably should write a long summary as well, as I did three years ago, but I rather continue with the findings from my current CodeCopTour. So if you want to know more about Devoxx 2013, please refer to posts other attendees have written, e.g. Bartosz Majsak, Peter Pilgrim or Steve Schols.

Conferences as part of a Journeyman Tour
This brings me to the topic of conferences. Conferences and other community related activities like Coding Dojos or Code Retreats are the perfect addition to a teaching and learning tour. For example Daniel Temme, who did a similar tour earlier this year, actually started his tour during the German SoCraTes conference and visited ALE conference in the middle of his tour. When you plan for a Journeyman tour, adding space for conferences and other technology related meet-ups is easy. Additional to learning something new, conferences provide you with opportunities to discuss your findings with other craftsmen and maybe even find new hosts for your continued tour. As you have no income commercial conferences are out of the question, unless you present something, like I did during Agile Testing Days.

CodeCopTour Week 10

For the tenth week of my Software Craftsmanship tour RISE, the Research Industrial Systems Engineering, invited me to stay for three days and I pair-programmed with Kilian Matt. Kilian had prepared some special work items for my visit and we started refactoring some old piece of legacy code. Kilian was happy because nobody would touch that code and usually he would not have time to work on it himself, but for my visit he had "made some time". We worked together well and I was productive as soon as we sat down to code. Together we made smaller steps in the refactoring than both of us would have taken on their own and we moved forward steadily. Kilian focused on using keyboard short-cuts and I learned some of IDEA's key bindings. In the end of the day we had typed 15.000 keys and clicked 1800 times, a good ratio according to Kilian. (The recording was done with Workrave, a little tool for monitoring your work to avoid Repetitive Strain Injury.) Kilian is a true Software Craftsman and I enjoyed working with him a lot. Thank you very much and special thanks for the cheese ;-)

The third day of my visit I worked with Zeljko Brdaric, who specialized in test automation and BDD. We added a small feature to his code base, and adding the test first I worked for the first time with TestNG. It did not make any difference as the annotations and assertions looked the same as in plain old JUnit. We had an interesting discussion about using present or past tense in commit messages. I liked this attention to detail.

Then I moved on to Dimoco, a company offering mobile payments worldwide. There I pair-programmed with Helmut Jelinek for two days. Helmut had arranged a meeting room for us so we would not disturb other colleagues in the open plan office. It was a very small meeting room, more like an aquarium ;-) I called it the "pair-programming cell", see its picture on the right. Helmut was responsible for Dimoco's reporting backend which collected events throughout the application and aggregated them for monitoring purposes and we added a small feature to its reporting backend. Helmut had a strict attitude about introducing zero defects and was very serious about checking, reviewing and retesting our changes. I have never met a person checking his or her code so closely. Obviously I liked that and will incorporate some elements of his work flow.

Remote Book Club
Besides pair-programming I finished reading Domain-Driven Design by Eric Evans in that week. I participated in a remote reading group, started by a former colleague Jonny Andersson, back in the days when I worked for IBM. Since January we have been meeting online each week and worked through 15 pages of the book each time. It took us 33 meetings in total to go through the 500 pages of the book and a few meetings were delayed due to public holidays or holiday time in general. We had many interesting discussions during the year which made reading the book more fun and the learning experience much richer. Jonny is preparing for the next reading group right now. It will start January 2014 and we are currently discussing which book to read. If you want to join us, stay in touch.

CodeCopTour Weeks 8 and 9

Today ends the tenth week of my Software Craftsmanship tour. I visited several companies, paired with many developers and discussed with even more people about our craft. My memories are blurry, there is just too much to keep track of. Fortunately I use a large notebook to collect thoughts and findings during my tour and it helps me to continue my diary about the recent weeks of my tour. As I need to catch up with three weeks by now, this one is going to be brief.

Week 8
I started the eighth week of my tour visiting Codeship, a Vienna based startup offering hosted Continuous Integration and Continuous Deployment solutions for many technologies and hosting platforms. Together with Codeship's development lead Clemens Helm I worked on a feature deep inside the Codeship's Ruby on Rails core. Clemens, of "Testing Tuesday" fame, created a guiding test with Cucumber and then switched to RSpec unit tests for the details. It was a great pairing experience despite that my Ruby skills have degraded considerably causing me to slow down Clemens a bit. Between pairing I joined the Codeship team playing some rounds of tabletop football and improved my skills there as well ;-)

Then I spent three days at Irian, a Java Enterprise consultancy famous for co-founding the Apache MyFaces project. I worked with Jan Zarnikov on a new application in TypeScript. TypeScript, the new open source language from Microsoft, was designed for application-scale JavaScript development and compiles to plain JavaScript. I had never heard of it (it was just created last year) and Jan was concerned if I would be able to work with it. But I had no problems and we made good progress. Jan had prepared all the details in advance and we were just banging out the first version of a touch enabled learning game, driving the whole development by tests. It was awesome! Typescript looked cool and was easy to work with, just the development environment and infrastructure (outside of Visual Studio) needs to catch up.

Dojo Week 9
The following Monday I facilitated an in-house Code Retreat for two development teams. Although there were only ten participants, the final retrospective showed many learnings, which was proof for me that the Code Retreat was useful for them. I want to point out how great this Vienna based company is. Running Code Retreats as part of developer education is awesome and I only know a few companies that do things like that.

The rest of the week I attended the Agile Testing Days 2013, an annual European conference. I had been invited by the organizers to run the Coding Dojos each afternoon of the conference. I chose three different katas for the Dojos to keep things interesting. I started with Refactoring the Tennis Kata, a kata designed by Emily Bache. The provided source code of scoring a Tennis game was awful but had a comprehensive suite of automated tests which allowed the participants to focus entirely on refactoring. All seats were taken and we had a great Dojo with good discussions in the end. The following day I helped the participants to Design Test Cases for the Gilded Rose Kata, originally made up by Terry Hughes and modified by Emily Bache. The prepared code base contained some (spaghetti-) business logic but no tests. The participants were asked to add test cases. Again we had a great Dojo with good discussions in the end. For the third Dojo I had prepared the exercise of TDD as if you meant it, as proposed by Keith Braithwaite. I considered it a difficult exercise and the participants were struggling with the concept in the beginning. After some time they made progress and even skipped the break to enjoy pair programming for additional 25 minutes. Obviously they meant it ;-)

I did not pair program with anybody during this week, but learned many new things in the conference sessions and taught a few things to the participants of the Coding Dojos. I had great discussions in the evenings with like minded people and made some new friends as well. Food was provided at the conference venue and travel cost was refunded by the conference organizers. All these facts come pretty close to the requirements for my Journeyman Tour ;-)

How to sell a Journeyman Tour to Management

I have been asked by several fellow craftsmen how to sell my Journeyman Tour to management. When preparing my tour I had to help people willing to host me to convince their bosses that my visit would be a good idea. Here are some points you might use to justify a Journeyman visit.

Corey Haines did not write anything about convincing management in his Journeyman blog back in 2008. Earlier this year I sent him an email asking for an advice. Although I believe Corey is a busy man, he answered my question. Here is what he wrote:

I'm afraid that I don't have a lot of advice on pre-selling the idea to management. I stayed away from companies that had trouble figuring out the value of having me there. Especially at the beginning, a lot of companies were a bit worried about the idea of having someone in. I just started without them. One major advice I have that is based on my experience is to just start. I didn't really plan things out too far in advance, especially at the beginning. If you just start going to some of the places that you do know, then others might start to turn their attitudes around. Make sure that you blog, do videos, etc, to get the word out of what you are doing. That way, companies will have something to focus on when they are making the decision. (Corey Haines, private mail, 29th of July 2013)

Start with companies who understand the idea.
So the first plan is not to convince management but just start with companies who understand the idea. This surely works if you travel a large enough area, as Daniel Temme's tour around Germany shows. So try to travel an area as large as possible.

Ask startups and small companies to host you.
As far as I noticed, small companies are more likely to host you. I started my tour with two startups, Blossom and letsplay.io because their founders just agreed to my visit without any questions. Especially the lean startup movement is open to the ideas of learning and continuous improvement. People running one-man businesses who are not permanently working at the customer's site seem to be more open to visits as well, e.g. Lunifera or sdguide.org.

Show that you are valuable.
As I want to stay in Vienna and the Journeyman concept is hardly known here, I have to convince some companies. Obviously there are benefits in having an outsider in your team for a few days. I start the "convincing" with describing my skills and enclose a current version of my CV that shows my experience and my willingness to teach, for example I list my talks at local user groups.

An outsider has a fresh perspective.
Even an outsider can provide valuable input. This is the main argument used by German coach Ralf Westphal who did a Journeyman tour this spring. This input might be some piece of code or just a second opinion during pair programming. As an outsider I am not affected by organisational blindness and can reflect on structures, assumptions, conventions and behaviour without adhering to company policy or any personal interests. I can share my views on coding, design, architecture, development process and anything I see during my visit. My host will benefit from my visit.

Help with Agile practices.
Related to a fresh perspective, I offer to help my hosts with Agile practices like TDD or pair programming. I will not run workshops or give polished presentations, but obviously I will practice with my pairing partner. I also offer to give a short presentation about the Journeyman concept and Software Craftsmanship in general which I have given several times since the beginning of my tour.

My friend Thomas Sundberg pointed out that managers of development teams who want to introduce pair programming or TDD into their teams should be interested in hosting Journeymen. By working closely with someone who has experience in pair programming, the developers will get a first impression of how it is done. This is especially valuable if they have absolutely no prior experience.

Knowledge is spread effectively using Pair Programming.
All the things said about outside view are even more true in the small world of a (programming) pair. As much as you hope to learn by pairing from a stranger, as much the stranger will learn from you. As the Code Cop I love unit testing and clean code. I do not know the domain I will be working in, but I know testing. My pair will know his or her domain, but maybe not how to create a good unit test, so we will work together on the domain with good tests. The same is true for clean code. One of my hosts invited me for exactly these reasons. The managers of the development department had tried to grow an atmosphere of professionalism and supported pair programming and TDD but the development culture had not changed. Of course my visit did not change it either, but at least I told the developers the same things their managers had been telling them and a few developers experienced these things while pair programming with me.

Spread the word about your tour.
As Corey said in his email, it is crucial to show what you are doing. It probably helps if you are well known like Corey or Ralf, but it is not necessary. I did not write any technical books nor do I speak regularly at conferences. I just started my tour with writing about my idea and added smaller posts on the way. People who wanted to pair with me showed my blog to their boss to explain the concept. I got invited to Germany based on the fuzz I created on Twitter. You should tell everyone about your tour in advance, present it at local user groups. You need to do some marketing. For example Ralf Westphal had his tour published in a high-circulation developer magazine and got much more offers than he had planned for.

You need a champion vouching for you.
In my experience the most important fact is the "mole" inside the company. Someone who understands the idea and wants to work with you. In the end he or she has to convince management and possibly vouch for you to be admitted. This person is a like-minded individual, someone whom you know from user groups or conferences. Especially Craftsmanship related activities like Coding Dojos, Code Retreats or Software Craftsmanship conferences are the right place to meet these people. As Daniel Temme wrote, his tour was based on people he had met during the SoCraTes 2013 conferences a week before. Saying that it is high time to say a big thank you to all the people that believed in me and convinced their managers that I would bring value to their organisations. Thank you all, you rock!

CodeCopTour Week 7

I think it would speed things up if I cover two weeks of my Pair Programming Tour in one swoop, as I did two weeks ago. I want to share some insights besides the usual diary, so I need to increase my writing throughput. On the other hand I do not like going faster because writing a blog post takes as long as it takes. Although I know people who do speed blogging, the OCD part of my personality does not like short-cuts, obviously.

Last week I was hosted by Thomas Baldauf of the Austrian Environment Agency. I did not know Thomas but had got his name from a friend. After a short email he immediately agreed to host me without any questions which surprised me a lot. Unfortunately Thomas, the lead of the development team, did not have time to work with me in person but had prepared some developers from his team for my visit. I worked with Nexhat Gashi on a small feature of their newest web application which is based on JSF technology. I did not know JSF before I started my tour, but saw it all the time when pairing with people. Probably I will be fluent with JSF until end of November ;-)

I also worked with Martin Lackner whom I knew as long time attendee of our Eclipse DemoCamps in Vienna. Martin, an Eclipse platform veteran, worked on an MDA prototype using Xtext. I had worked with the older versions 0.7 and 1.0 before and he had prepared all the nitty-gritty details in the previous week. I reviewed his DSL and probably spoilt all his fun by proposing a different, shorter syntax. We moved forward very fast. In only one day we created a technical language to define entities and aggregates, together with full editor support, code completion, validation and proper formatting. Such is the power of Xtext - I love it. If you do not know Xtext, I really encourage you to check it out. The Eclipse Xtext project has excellent documentation and many examples which provide a starting point to get your DSL up and running in no time.

Free Lunch
The only compensation I asked for pairing was food and beverages throughout the day. It worked out well - till now I have been provided with free lunch every day. All my hosts were very polite and offered me coffee or drinks and asked me for my preferences when choosing places to eat. I never asked for anything special but went for lunch where my partners went. I visited take-away noodle stores, staff canteens and fancy restaurants. Having lunch with many people, together with the various places in Vienna I have been to, was a culinary trip of its own.

The two weeks I spent away from home, I stayed in a hotel. The host company refunded me 600 Euro for my expenses per week. It was a nice hotel, expensive but comfortable. The money was sufficient because I saved on food, eating in the company canteen now and then. Staying in a hotel and working all day was acceptable for the two weeks, and I enjoyed the rich breakfast buffet including bacon and scrambled eggs. But I would not like to stay in a hotel for extended periods of time. I am not a travelling person and I never worked like that. I enjoy going home after work, where connectivity is good and wireless network is free ;-)

Can PL/SQL be Clean?
At the end of the week I spoke at the Austrian Oracle User Group. The organizer had planned an event focusing on clean development and three friends had recommended me to him independently. I agreed to give a presentation but was not sure about the topic I should talk about. For talking to an Oracle user group, the first thing that came to my mind was PL/SQL, Oracle's database language. I have seen horrible pieces of PL/SQL and the question was if it can be written in a clean way? According to Michael Feathers, the author of Working Effectively with Legacy Code, "clean code looks like it was written by someone who cares." I presented his quote as first rule of clean code. Continuing the discussion I listed several books about clean code, including Code Complete by Steve McConnell. Steve said to "write programs for people first, computers second", which I defined as second rule of clean code. Following both rules it was obvious that even PL/SQL can be written in a clean way. I got good feedback on my presentation, especially that it was very entertaining, so I encourage you to check out the slides on Slideshare.

Awesome Week 6

Journeyman Tip: Plan for some space each month
I try to keep the pairing sessions of my Journeyman tour free of any appointments. If we spend only two or three days I do not feel comfortable in coming late or leaving early, there is just not enough time. My calendar was blocked by pairing sessions entirely until my first "free" day last week. It was a busy day, and I used it to prepare a few things for our upcoming Eclipse DemoCamp in Vienna. And I had a job interview. (The position looked cool but in the end it turned out the vacancy was not for a developer but for a Unix sys-admin guru, someone who compiles his own kernel for fun now and then.) They day was too full, I had packed too much into it. So I recommend leaving one or two days without any pairing session each month, to catch up with all the things that need to be done. Corey did the same thing, splitting his journey into tours of up to four weeks, and also Daniel Temme ended his Journeyman weeks after four weeks.

Week Number Six
The remaining days of the last week I visited SIB Visions, a company focusing on the simplification of the software landscape used to support business processes. The backbone of their application stack is the JVx Enterprise Application Framework which was open source right from the start. If you need to build a typical business application to edit data in table- or master-detail-style, this is the framework you want to use. Check it out!

First I paired with René Jahn, SIB Visions' Head of R&D. He had a list of things he wanted to discuss with me. We started with the build. I complained that it was too slow, running longer than a hour, and that there were failing tests. We immediately started fixing them. Then René showed me the framework and I was impressed. The JVx code-base is following a strict standard defined by René, covering documentation, naming and much more. While I did not agree to some of his conventions I did admire the consistency in the code base. I believe that consistency is crucial for quality of a code base, some time ago I even declared it the First Law of Code Quality. Well done JVx team, I like that ;-)

Then I worked with Martin Handsteiner, CTO of SIB Visions, on a particular tricky problem. A main class of JVx' data model had grown larger than 5000 lines and needed to be split. Due to performance optimizations it worked with plain object arrays internally, following the Flyweight Design Pattern, which did not make it easier to understand. We fought the beast for two days and were able to split away a few hundred lines of code. It was hard work, but just the beginning of a longer rework Martin had estimated to take two weeks. It should never have become that large and entangled in the first place. Martin had always wished for a keyboarder/keyboardist and a "mouser" and thus stayed in the navigator role for most of the time. While it was unusual for me to be the driver for extended periods of time, it worked out well because Martin knew the concept of his model and I was moving forward relentlessly.

Just yesterday I received mail from René telling me that his build now takes nine minutes, 900% faster than last week and that all tests are green. I was delighted. For the first time one of my hosts had taken my ramblings serious and immediately fixed the issues. Awesome, that is the right spirit. Keep up the good work!

Remote Pair Programming
Even more awesomeness happened at the weekend. My friend Thomas Sundberg asked me for help with his presentation on (Remote) Pair Programming at 33rd Degree for charity in Kraków, Poland. He needed a remote pairing partner for a small demo. We frequently do remote pair programming katas since more than a year and were sure we could pull it off. During lunch break we tested connectivity and the audio equipment of the conference venue, to make sure that everybody would hear me. During the demo we did a few cycles of TDD, discussing names and refactoring the code in ping-pong style as usual. I was sitting at home, still contributing to a conference talk - it was awesome!

CodeCopTour Weeks 4 and 5

Today The day I started writing this post was the first day since more than five weeks that I did not schedule any pairing session. Somehow the day stayed blank in my calendar. Still it was a busy day. I spent more than four hours on emails, preparing stuff for our upcoming Eclipse DemoCamp and in the evening I attended an user group meeting. There was just enough time to squeeze in a blog post about the last two weeks, the fourth and fifth week of my CodeCopTour. Both weeks I visited a larger IT service provider. As I tweeted earlier this company wanted to stay anonymous for reasons I will explain later, so lets just name it Reynholm Industries. When planning my tour I had aimed for sessions of two or three days with each host but the management of Reynholm had invited me for two full weeks to visit several teams and pair with different people. I agreed and they had prepared for my visit three months in advance, at least that was what I thought.

Legal Issues
Obviously Reynholm was large enough to employ one or more legal advisers and they were afraid. I would work for Reynholm for two weeks and would not get any money. Nobody would believe that, so Reynholm might be accused of employing me without paying taxes. Austria has mandatory social insurance and its institution is lacking money and tracking down all possible cases of black market work to collect their share of the salary. In the morning after I arrived I was brought to the legal adviser and he told me that we had to cancel my visit. After preparing my visit for three months he had started his work one day before the deadline, my arrival. I was not amused and in no mood to drive back two hours with my business here unfinished. It took us half a day to work something out. In the end I signed a contract, accepting the responsibility to pay taxes for my income as necessary and I paid for the hotel and food myself. The fee of the contract was exactly the amount of money Reynholm had planned for my expenses, which was pretty accurate. I hope that in the end I will get back all the money I spent. Working on a contract and spending all income on expenses also does not sound reasonable, and I hope I will not get in trouble with the tax office.

First Code Retreat in Graz
Being in the area of Graz I used the opportunity to meet with my friend Wolfgang Kaufmann. Before I arrived I had talked to him about running a Code Retreat in Graz and he immediately agreed. He brought in some of his colleagues to help us organize and even talked his employer INFONOVA into sponsoring the coffee and lunch during the event. The local university FH Campus02 let us use one of its lecture rooms and we were ready to get started.

After morning coffee I introduced the participants to the idea of Code Retreat and we started practising TDD, pair programming and object orientation.

During the first session almost all teams used arrays of integers or boolean flags so I chose No Naked Primitives as constraint for the second session. During that session only one pair worked on the business rules and all others created only infrastructure, so I proposed to focus on the domain in the next session. Lunch was great, we had wine and beer, several main dishes, even cheese and sweets. It was luxuriant - thank you INFONOVA. (I know I already mentioned them, but the lunch was really awesome, so one extra link will not hurt. Did I mention that they are looking for all kind of developers, just check out their web site ;-)

After lunch we had a session of Ping Pong Mute, which was really fun. One participant complained that he could not go for a design he wanted to try because his pair would not understand it without long explanations. I liked the idea of measuring a design by its simplicity - by its ability to be understood without much discussion. Probably his idea did not follow the KISS principle. After another round I asked the audience what they would like to work on in their last session and Wolfgang proposed No Conditionals. Although this is one of the more difficult exercises they came up with great solutions using nested maps or state machines.

It was a very nice Code Retreat. The 15 participants were a good mixture of junior and senior developers, Scrum Masters and even one Product Owner who wanted to know what "his" developers do in their personal time ;-) People learned a lot, many of them had their first contact with TDD and pair programming in practice. Several decided to give TDD a try in their daily work. Thanks to our awesome sponsors INFONOVA and Campus02 we had everything we needed and the attending developers used the opportunity and made it a great event. Thank you all!

Second Week
In the second week I continued my journey through different teams at Reynholm and paired with different people for a day. All developers I met were friendly and open and I had a lot of interesting discussions. I already knew many people from the previous week and kept meeting known faces in the hallways and during lunch. At the end of the second week I felt like I had been with Reynholm for a long time and I even felt a bit sad I had to go away now because the people were so awesome. Thank you Alexander, Andreas, Andreas, Bernhard, Harald, Karl, Martin, Peter, Robert, Sabine, Stefan, Tom and Wolfgang. I will miss you.

CodeCopTour Week 3

I was waiting for the legal advisor of TechTalk to review the five lines I wrote about my visit at their office the week before, which caused some delay in my blogging queue, but now I am back on track and will continue with week number three of my tour. I started the week with going to the country-side of Lower Austria. While driving I reflected about my tour (and I already published my thoughts here). Markus Schinerl had invited me to stay at his house for three days. Markus runs a small company called sdguide.org which is specialized in calculating metrics like the carbon footprint for factories in the pulp and paper industry. Pulp and paper is a very competitive industry and customers like governments demand the highest environment-conserving certificates from their paper providers. Sdguide's office was located in an old house and due to old age and structural damage it was under construction and looked terrible, see the image on the right side. Some windows were broken and we worked on a raw, wooden construction resembling a table. However we had a powerful computer, two keyboards and two huge screens - no problem there ;-)

Spreadsheet Monstrosities
Markus used a gigantic spreadsheet to enter all parameters needed for such a calculation. It contained roughly 200 input parameters and 500 metrics for up to 50 product parts resulting in huge files with thousand of lines. Obviously Excel was reaching its limits and he needed something more powerful. We spent the first day discussing the domain of carbon footprint and created a small diagram defining the core elements of his calculations. Although we did not write any code it was a productive day because I helped Markus to reflect on his needs and he explained the requirement to me at the same time. We came to the shared conclusion that he needed a real database, but one that he might be able to develop himself, so we ended with Visual Basic (for Applications aka VBA) and MS Access. Although I did not fancy VBA it was the best choice for his needs and he liked the idea that he would be able to use parts of our VBA code in his spreadsheets as well.

Markus had used VBA some years ago and I had never worked with it before. It took us half of a day googling and reading StackOverflow until we got fluent and then we flew. VBA does not offer much and I missed a lot like unit testing, collection classes, closures and much more, still we made good progress. At the end of the second day, actually the very end of the day - it was 10pm, we had built full end-to-end functionality. Of course it was not finished and only calculated one simple formula of one metric for one product part without considering scenarios, different years or different customers. Still it showed the way. I had aimed for that because we needed to know if the chosen design would work. It looked good. During the third day we added more features Markus wanted to investigate, we even created an infix math parser to evaluate arbitrary formulas. It was great and I learned a lot.

Being Brutal
Back in Vienna I helped a small team of developers to improve their refactoring skills. The developers liked practice and I chose Adrian Bolboaca's Brutal Refactoring Game. I had participated in Adrian's session during XP2013 earlier this year and had liked it a lot. It is a programming challenge focusing on refactoring. The brutal part is that each code smell needs to be refactored right now, regardless how small it is. This makes an excellent exercise to train developers in spotting code smells and refactoring them. Adrian lists 17 code smells as the base of the game and I asked the team to prepare short presentations about each of them. At the beginning of the session the developers presented the material to the audience. I just love when trainees teach themselves ;-) During the sessions I collected all the smells I had flagged. Half of them was about naming, i.e. "name not from domain" and "name not revealing intent" which did not surprise me because naming is a difficult problem. Further 30% were "Primitive Obsession" and "lack of tests", common problems in most code bases. One participant was disappointed that he did not hit each of the 17 smells at some point during the game - maybe I will add some game like achievements for completionists like him.

Even for a small group it was demanding to watch out for the smallest code smell in several evolving code bases at the same time. I noticed that pairs kept hitting the same smells again and again. Besides naming, which all participants had to deal with, one pair was "obsessed with primitives" several times, whereas another team had trouble writing tests to cover their design ideas. A fast typing pair, two developers who knew their IDEs well, created a lot of code, but as soon as I found a smell they were unable to remove it by refactoring and had to delete the new code and start over. Although I was as brutal as possible and challenged the participants a lot, I got positive feedback after the exercise and all participants learned something.

The Java User Groups of Austria
For the rest of the week I went "on tour" with the Java Klassentreffen 2013. The Klassentreffen is a series of events organized by the Austrian Java training company Ciit and sponsored by Oracle. It is a mixture of sales pitches and technical presentations, covering various aspects of Java. Technically the Klassentreffen did not meet my requirements for the pair programming tour, but the organizers had invited me to speak and food was provided. Together with Martin Ahrer, the founder of the eJUG Austria, I introduced the audience to Java and Java related user groups in Austria. I started my talk with the reasons to attend user groups, then covered the core groups of Java, Eclipse, Android and Scala and finished the presentation with Open Source, Software Craftsmanship and upcoming Code Retreats. (For details and links please open the slides.) Later the leaders of several groups told me about new registrations, so I guess my presentation was a full success.

CodeCopTour Week 2

Culture Shock
My second week's journey brought me to the highest towers of Vienna (see picture on the right). After previous week's startups this felt different. Paul Rohorzka had invited me to join him for two days. I had not known Paul before but had seen his name on the manifesto. Later when I met him in person during a Code Retreat I told him about my tour and he immediately agreed to pair with me. Working for a regular company TechTalk he had to get permission for my visit which took some time to figure out but finally he managed.

In the morning Paul surprised me with a list of several things he wanted to work on. On his current assignment he worked alone and lacked potential reviewers and therefore wanted several pieces of his code discussed. He had prepared his expectations, work packages and a list of verification "milestones" for these two days. After previous' week marathon coding sessions I felt like using Pomodoros and his work packages were sized small enough to fit into Pomodoros which we kept doing both days.

On the first day we worked on improving the readability of his specs. He used SpecFlow, a BDD testing tool for .NET, which worked just fine. I am generally disappointed by .NET tooling, but I was positively surprised how nice SpecFlow worked, just like you would expect it to work. Although we did not finish the work on the specs, Paul wanted to work on something else the second day, to get as much coverage of his work as possible. We dived into test infrastructure and reworked the part for creating test data. Its core class really needed some refactoring and we spent the entire day cleaning it up and making it ready for new features Paul knew he would have to add soon.

Paul is a true craftsman. I thought that I was a structured worker, but he was much more structured than I, which was nice to witness - there is always room for improvement ;-). Although I had never worked with C# before we had a shared understanding and were productive after the first hour. I enjoyed working with him and had a great time. Thank you Paul.

In the middle of the week I moderated the September Coding Dojo of the Scala User Group Vienna. (A Coding Dojo is a meeting where a bunch of coders get together and work on a small programming challenge to improve their skills. You can find more information about Coding Dojo in Emily's excellent Coding Dojo Handbook.) It was their eight dojo and I wanted to try something more advanced than basic code katas. I chose the TDD as if you meant it exercise by Keith Braithwaite. This was a difficult exercise and it was difficult on purpose, but the participants did well, much better than I did my first time during GeeCON 2012. It was my first time facilitating and their first time working through this exercise, and all of us learned a lot.

Yak Shaving
The remainder of the week Florian Pirchner hosted me in the office of his company Lunifera. I knew Florian since several years as organized the Eclipse DemoCamp in Vienna together. Lunifera was a development shop specialized in OSGi technologies and its "office" was still located in the living room of his flat which made a comfortable place to work and we had a lot of fun. But the work - the work was terrible and we spent almost three days Yak Shaving.

When I arrived at Lunifera, Florian showed me his current pet project, a radio controlled air swimmer, a flying shark, using BeagleBone, Arduino, many cables and - of course - OSGi technology. He prepared the project for his upcoming talk at EclipseCon Europe and needed some third-party code deployed to Eclipse Virgo, an OSGi compliant server. And it just did not work. After reading the documentation several times, we started from scratch, took baby steps and reproduced the smallest examples from the documentation. Based on these working Virgo examples, we moved forward to implement the code he needed, a m2m server based on Apache ActiveMQ. Besides some integration tests, we did not write a single line of Java, but many lines of poms, manifests, Spring and other XML configurations. I hate infrastructure work. Finally we got it to work and Florian was thankful for my help on this task, I even got a new nick-name "Config-Cop" ;-)

Journeyman Tour is hard work

The post about my second week is ready since some days but I am waiting for it to be reviewed by the company I visited. In the meantime let me tell you about some other aspect of my Journeyman tour.

At the beginning of the third week I drove to the country-side to pair with an old friend. While driving, I used the time to reflect about my tour. The quiet activity of driving seemed to support reflection. At some point I stopped to take notes so I would not forget, something that Corey called Road Thoughts. Corey recorded several of them during his tour as he drove around all the time.

Preparation takes time
A Journeyman tour might be seen as a funny or exciting undertaking, which it certainly is, but most of all, it is hard work. It started with the preparations, which were time consuming. Over three months I spent considerable effort in contacting people, promoting my tour, and finally finding individuals who would host me. I regularly spent two hours on emails, usually after regular work in the evening. Because I wanted to do my tour in Vienna, and because Software Craftsmanship is not widely known there, I needed to explain the tour, my motivation and potential benefits to future hosts and their managers again and again. (I will discuss how to sell such a Pair Programming Tour to management in a later post.) I roughly spent a man-month (160 hours) on preparations and discussions to find 20 to 25 hosts who would host me for a total of three months.

I never worked that hard
Facing a new project every three days is exhausting. There is no time to get used to it and obviously I want to be productive as soon as possible. New projects with new technologies in new domains are not a problem by themselves, but the cognitive load is extreme. There are many things I learn every hour and I constantly need to do things I never did before. I assume digesting this new knowledge comes "with a cost" - I am very tired in the evenings. I work with my hosts from morning to evening, usually seven to eight hours and after work we might add a retrospective or discuss some geek issues while drinking beer. Surely I overdid my tour by attending as many user group meetings as possible to promote the idea of Pair Programming Tour.

Pairing is intense
I try to pair 100% with my host. Even when Nik had to write a technical mail regarding Dart build issues, or when Florian had to create a cash flow spreadsheet for an upcoming project, we worked together. Pair programming is more demanding than regular work. There are no distractions, no mails or Twitter, because we are working on something. We keep each other focused all the time (and sometimes skip breaks or forget to drink which is a bad thing). This work is intense all day, five days a week.

Personal Pressure
The uncertainty of a new host, paired with possible expectations they might have, make me uneasy. What is my host really expecting? Will I fail? Will I look stupid? I know that there is no failing, still the thoughts of doubt are here. I feel the need to get something done, to deliver some value. This is my personal commitment for my host. On some occasions it caused me to take short-cuts during pair development, which I had never taken before and should not have taken at all.

Sharing needs time as well
Finally I want to blog about my tour. Summarizing what happened during the week is important to reflect on the things I learned. I found many things I need to share with future Journeyman, observations about our craft and other fascinating topics. Also people keep asking me about my tour. I initially planned to write blog posts twice a week, one diary and one about some discovery I made. I am a slow writer and I am two posts behind schedule already. But I promised Corey Haines himself that I would write about my tour. He is watching me, and these posts will be written ;-)

Journeyman Findings 1

Here are some notes I took during the first week of my Pair Programming Tour.

Discuss the expectations with your host up front.
At the end of each visit I do a short retrospective with my host. After pairing with Nik Graf for two days, we did such a retrospective and I found that he had different expectations for the past two days. He had paired with other people before, usually technical experts in one or the other area of the Blossom technology stack. He and his pair would hack away deep inside the bowels of Blossom code and get things done. When I joined him, he had to fix a potential security problem and we worked on some Google App Engine specific part of the application. I learned a lot but was not able to contribute much on this level of detail. I helped him with changes and offered general comments and advice on build, testing and deployment - whatever we touched during our work. That was not what he expected, nevertheless he assured me that my contribution was welcome, just on a higher level, "in a way how he had not looked at his application since a long time". We should have discussed his expectations at the morning of my arrival.

An initial design might block your options.
When I paired with Raphael last week, we discussed his needs and came up with a small drawing depicting a possible design. Coding went well for some time and we followed our design that I jokingly called our BDUF. After building several classes, Raphael noticed that he needed a feature that he had not thought of before. Instead of embracing the change in our design, I somehow did not like the idea and talked him out of it. In the evening during our daily retrospective we discussed what had happened. The needed change would have destroyed the initial design but I liked it and was almost proud of it. Subconsciously I had rejected the idea of a change that would invalidate my plan. I did not know that it was because of the design up front until we talked about it.

Bring keyboards for all languages used in your area.
Even when pairing on a small laptop an additional keyboard and mouse allow to change between driver and navigator roles more easily and so I brought my own keyboard with me right from the start. In Austria we use German keyboard layout but some developers use English laptops or just like to use English keyboards. Raphael used an English keyboard and showed me where to switch layouts, so I would be able to work with my German keyboard as well. Switching keyboard language took time and we forgot about it often resulting in both of us typing wrong keys. I knew the English layout and we decided to stay with it. Then I was struggling to find the proper keys for special characters like {}. On the next day I brought an English keyboard which resolved all my typing issues.

This is a positive experience!
When I explained my tour to some fellow coders, one asked me if I would create a list of worst code I have seen. I answered him that this tour is a positive experience. I have worked for big companies and I already know how bad code can look like. I assume that in the last 14 years I created more bad than clean code myself. I will not collect any findings because I am not interested how bad your code is. I am interested how you work and how you try to improve your code. Hosting a journeyman for a pairing session is a sign that you want to grow and I can show you how to fix that legacy code.

CodeCopTour Week 1

Finally my Journeyman tour started last week. My first host was Raphael Stary from letsplay.io, a fresh startup creating the next level of social games. The "next level of social games" sounded like a mixture of FarmVille and World of Warcraft ;-) - playing with your friends using your mobile phone - hot stuff! Raphael was very kind and it was a great experience. After some initial chitchat he revealed his plans for me: to use my Java skills for creating the server side component of his newest game. We spent three days pairing intensively and I was happy with our result, an almost complete back-end including integration tests. All the discussions about the domain and the technical details of browser based games sparked the idea to create my own game. I used to code little games many years ago and had forgotten the joy of doing so. Maybe I will create something small after my tour when things have settled down again.
Being in Sektor5, a relaxed local coworking space, I took the opportunity to visit another startup, Blossom, a lean Kanban board. Blossom was founded a few years ago, and after winning some funding they mainly operate in the San Francisco area now. Blossom has customers from companies like Twitter or Google, an impressive feat for a Viennese startup. Blossom CTO Nik Graf paired with me for two days. He showed me their impressive technology stack and I saw many technologies I had never seen before, probably too much to digest in two days. I enjoyed the atmosphere of a real technology startup. Rock on guys! (I confess I am a Blossom fan boy now, just like half of the coworking space ;-)

During my tour I plan to visit as many user group meetings as possible. The Vienna Ruby Group meets in the same coworking space and I squeezed myself into the agenda and introduced the Ruby enthusiasts of Vienna to the idea of Software Craftsmanship and the Journeyman Tour. After the presentations we had a great discussion about craftsmanship, pair programming, and quality in general. I liked talking to passionate developers and will attend future meetings as well.

Last week was a blast. I learned a lot both about our craft and myself. My journal is full with notes and findings, which I will share in shorter posts in the next days.

This Is Madness

Two months ago my time with Big Blue ended. While preparing for my Journeyman tour next month, I sorted out my drafts of blog posts and rediscovered some notes concerning my last assignment in the company. It was a particularly crazy time and I only wrote about it to clear my mind. Nevertheless, such gems need to be shared. As usual all my writing is fictional and does not resemble any real people or companies.

For my latest assignment I joined another team. I was happy at first because I worked with a new prototype, which was a nice change from my previous waterfall project. The team was led by a Distinguished Engineer, so my expectations were high. But soon the forces of madness showed.

Roll Your Own
First I noticed that one developer had created his own in-memory document store to support OLAP style operations, mainly pre-aggregated sums. I was not sure why he had done that, he had not checked existing third-party products before, but I guess creating your own database is a fun project to play with. Unfortunately many concepts where missing and the provided generality was not needed. (Note: One Does Not Simply create his or her own database system during a development project.) As a new member I did not want to question him during my first weeks and just accepted it. Later when he wanted to add some features, he rewrote the whole thing from scratch during a weekend, dropping at least one month worth of my additions. I was not amused.

Web or Desktop Application?
The project was under active development for almost a year and the business stake holders had still not decided if they wanted a web or a standalone application. The core developers were used to Eclipse/RCP, so they had created a server-client application prototype. When the business was finally ready to decide, the whole team spent two days creating estimates for both variants. "Surprisingly" porting the already existing desktop client to the web was rejected as being more expensive. I guess the business did not really care. (Note: Architecture decisions need to be made early in the project.)

Upload a File
Users needed to upload a large file to the server which would take several minutes. It needed to be extra reliable (but the exact term of "extra" was never defined). So the whole team met online to discuss the issue. One developer had the idea to use messaging for the upload because "messaging is usually reliable" and the company's flagship JMS product was extra reliable. I could not believe it - WTF? The client would still have to upload the file to the server to put it into the message queue. Further messaging is not designed to work with huge files. I begged the lead developer not to introduce a new component only to transfer a several MB file from the servlet layer to the service layer. At this time I started sending emails with "Madness? No this is reliaaaaaaable".

From Prototype to Production Over Night
The project had started as research prototype with the goal to experiment and compare different algorithms. Some of the numbers did not make sense and were being discussed and changed by the business people every day. Suddenly things changed, the whole project became production software and a deadline came up. The deadline was - of course - completely unrealistic but nobody told the business. Further more, there was a strict protocol for production applications in the company which needed many documents and formal reviews. Creating these artefacts delayed the deadline, too.

The Grand Finale
For all this bureaucracy, a young developer was brought in as architect. He did most of the necessary paper work which really helped but then things got nasty. He introduced code reviews - which is a good idea in general - but his findings were useless. First he forced us to use a large JavaDoc template which introduced much noise into our classes and then he demanded that every method would log its entry and its exit. My heart sank, but fortunately my twitter followers gave me permission to ignore his rules ;-)

Again this is not much more than a rant, but it is also a true story. Some of my friends enjoy reading rants, maybe my stories reassure them that one should not work for large corporations.

My Craftsmanship Tour

In my last blog post I described Corey Haines' Pair Programming Tour. This post is about my own "interpretation" of a Craftsmanship tour and my plan how to get it started.

After working too many years for banks and big IT providers, I needed a break. I was fed up with low quality work and wanted a change of perspective. Also the idea of practice and mastery appealed to me long before the notion of Craftsmanship was born. All these things culminated in the idea to go for a Pair Programming Tour.

September 2nd
My tour will start at Monday September 2nd. Initially I planned for one month which would allow for eight to ten pairing sessions. Obviously I was aiming low. At the beginning of August all September and half of October were booked, so I changed my mind and will go on as long as I can find companies or individuals to work with.

In and around Vienna
For my first tour I will stay mainly in and around Vienna. Most of my professional contacts are from Vienna and I hope to find companies more easily by removing the need to pay a hotel room for me. Several people had warned me that the need of a budget to host me would complicate matters in Austrian companies considerably. By skipping the journey out of my Journeyman tour I might lose the benefit of having time during travel to reflect about what I just learned. I will see how that affects my tour. I got invited to visit other places in Austria as well and will stay in Graz and maybe in Salzburg for a few days each.

Pair with me
I am looking for people that will pair with me for two or three days starting this September. Two to three days seems a good time to pair with a single person. If there are more people who want to pair, I can stay longer. In Vienna I am asking for free lunch and beverages throughout the day. The only condition is that we will pair program. It should be a quiet time without meetings where you plan development activities on the mainline of delivery, e.g. writing code, writing tests or improve your build system. Even spiking or general discussions about coding, design or Software Craftsmanship in general are valuable to me. Whatever you need to do during this time, we will work on it. I will be a regular team member and will support you as much as I can. We can work together on Java SE/EE, Scala and Ruby projects. If we do some Java Script, R, Dart or Forth I am sure to learn a lot but will probably slow you down as I am not fluent in these languages. I propose we use your machine as your work might require specific set-up but I will bring my keyboard and mouse.

Finding a host
Three months ago I started preparing my tour. I created a list of the best developers I knew in Vienna and got in touch. People running startups, like Raphael Stary of letsplay.io, did not hesitate and immediately agreed with hosting me for some days. Obviously startups are flexible and many of them already practice regular pair programming. But most of my contacts had to ask their management and that was where the fun started. Hardly any company knew Software Craftsmanship or the Journeyman concept and many still did not believe in pair programming. Only due to the help of my fellow craftsmen I got invited to a few larger companies till now. My friends had to convince their management and probably vouch for me to get my visit approved. I am still working on ways to pre-sell the idea to management but it seems impossible to get into companies without a persuasive Craftsman-agent inside.

Fine-print for companies
Here are some points to clarify my idea for managers: I am not interested in your customer or the project itself, just the learning and sharing. I will sign any NDA. If you do not want to be mentioned, I will not use your company's name in any posts or tweets. I will blog about my experiences during the tour. If a post covers my visit at your company I will show it to you before I publish it.

My expectations
People asked me what I want to gain from a Pair Programming Tour. Obviously I want to learn new things. I will work with people I have never worked with, see how they approach problems, "steal" one or two of their tricks. I will see new projects and experience the development process of different teams. I hope to get new perspectives, to think outside the box. Like it was Corey's, my main goal is to improve, reflect on our principles and broaden my mind. Finally I want to raise awareness for Software Craftsmanship in my area. Just today I got an email saying that it is great that the Software Craftsmanship movement has finally arrived in Austria. ;-)

Conclusion
So if you are interested in broadening your mind as well and want to pair program with me for a few days, contact me!

Corey's Pair Programming Tour

After my last rant on the missing quality in today's mainstream IT I got several mails from friends who had heard that I had quit my job (for the same reason). They asked me what I was up to now? The short answer is that I am planning a Pair Programming Tour (called Code Cop Tour). The long answer needs more explanation.

The Beginning
Like in every good story, let us start at the beginning - well maybe not at the very beginning, but let us start with Corey Haines. In 2008 Corey Haines, an US based programmer, lost his job and embarked on an unique, personal "Pair Programming Tour" around central US. He was travelling around, practising software development, pair-programming with people for room and board (room and food). InfoQ posted a summary about his first trip back in 2008, that I will in part repeat here: ... Corey Haines has embarked on a tour in the name of increasing our industry's emphasis on software as a craft. ... While he has dubbed the tour a "Pair Programming Tour", its ultimate intent is somewhat less about the practice of pair programming per se than it is about the ideas of what it takes for a software developer to really become good at what he or she does. ... Haines has posted video interviews revealing many of the unique insights he has gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.

Corey maintained a blog On Being A Journeyman Software Developer throughout his travels where he recorded his insights. While preparing for my own tour, I read it all, right from the first entry. Here is my summary:

Several Trips
Corey spent an entire year being a Journeyman Coder. A few others have done similar trips, but much shorter. These trips have been called "Pair Programming Tour", "Journeyman Tour", "Software Craftsman Road Trip", "Software Craftsmanship Walz" and so on. He split his journey into short tours of up to four weeks, using a conference or another event as leg for a trip.

For a certain trip he picked a region to explore, reached out to people that he knew in that region and talked to companies in the area, looking for places to allow him to visit. He knew a lot of people who worked from home, independents and remote workers, who he might visit. He prepared a list of places up front, with 50% already filled with people to pair or companies that would host him. For the remaining time he maintained a Pairing Calendar, that people interested in hosting him could look at.

Pair Programming
In general he spent between one and five days with people, usually two or three days, pair-programming on whatever they wanted to work on. He worked with people of widely varying experience and skill level on various projects. Due to the high density of well known individuals in his area he was also able to work with book authors, open source project leads and celebrities like Uncle Bob. He saw many aspects of software development, gained exposure to new software tools, learned new coding tricks and thus both actively trained others and got trained himself. (Pair Programming is next to many things a powerful technique for sharing knowledge.)

When visiting companies (I assume) he was just another member of the team and contributed as much as possible. Still he was an outsider with his own views and experiences, who most likely acted as agitator as well. (Obtiva's Jake Scruggs explained the role of agitator in his report about the 8th Light vs. Obtiva Craftsman Swap: The workers all believe the same, so they do not have a hard object to push up against. They got to sharpen their edges on me, and I got to sharpen my edges on them.)

Reflection during Travel
Between pairing sessions Corey drove around the country. He used the long road trips to think about what he had learned and reflect about conversations. He said himself that My head was so full of thoughts after the intense discussions with people; I just had to stop and record my very first "road thoughts." Maybe not by his planning, but this was an important part of a learning tour. To emphasize learning, we need to revisit the material studied before, reflect on it, sort it out.

Teaching
To Corey teaching was as important as learning. He updated his blog regularly, discussed new ideas or revisited old concepts. Next to recording his road thoughts he made several video interviews with people he had paired with. He talked at conferences and spoke at user groups on his way. Later he travelled around and organized Code Retreats in various places. He convinced people that software is a craft and explained the idea of Software Craftsmanship in general.

This is my understanding of the "classic" Journeyman Tour - and exactly this is what I will do. I am planning my tour since two months and in the next blog post I will describe my Code Cop Tour. Stay tuned ;-)

Word Wrap Kata revisited

Last year in November, my old post about Word Wrap Kata variants suddenly got a lot of visits. Claus told me that well known German blogger Ralf Westphal had linked to it from one of his own articles about Test Driven Development. By using examples from Coding Dojos he explained that using Test Driven Development alone is not enough to get clean code. During the Dojo the participants focused only on the red and green bars and other concerns like design or code readability were neglected. He used my code as examples of solutions got by such a behaviour. While it made me unhappy to serve as negative example, I had to agree with Ralf. When I performed the katas two years ago I explored different algorithms and did not use them to practice TDD. My solutions were technical, instead of reflecting the problem domain.

When I attended a Coding Dojo afterwards I paid close attention and was sad to see he that all Ralf's concerns came true. The group did not even understand the requirements completely, when people already started proposing language features and libraries which would solve the problem quickly. Solve which problem quickly? We should think about the problem first and then create code driven by our tests that is clean, readable and open for future change. Ralf had some ideas how to improve these issues behind programming. Obviously code needs to have many qualities beyond its simple correctness.

So I tried again. I got help from my friend Thomas Sundberg and we worked five remote pairing sessions on the Word Wrap code kata. We performed the kata in the "usual" way, without much thought up front and being driven by our tests. Similar to a Coderetreat, we chose additional constraints: We focused on business related names, SRP and Tell, don't ask. As a kata is a learning exercise, we took everything to the extreme. We literally spent hours discussing if a particular name was reflecting the problem domain, renaming it three times or more until we were satisfied. And we spent at least six pomodoros entirely on refactoring and cleaning up. Probably we could still improve it but we grew tired of the exercise and switched to another kata.

When I see the code now, it looks a bit weird, likely because taking "Tell, don't ask" to the extreme means never asking for any state. So the first thing we need is a class that receives the wrapped output, as we cannot ask for it. Word Wrap is an algorithm inside a word processor when a paragraph of text, which does not contain any newlines, is rendered to a page where it needs to be broken into lines of proper length:

interface Page {
    void renderLine(String lineOfProperLength);
}

In breaking the paragraph into lines of proper length, we see several responsibilities: splitting the paragraph,

interface ParagraphSplitter {
    void wrap(String paragraph);
}

which breaks the stream of text down into words, accumulating the words into lines of proper length,

interface LineAccumulator {
    void addAndHyphenateIfNeeded(String word);
    void addWithoutHyphenation(String part);
    void addCarriageReturn();
}

and maybe a hyphenation rule to determine if a word which is too long can be broken into shorter pieces,

interface HyphenationRule {
    void doHyphenate(String word, LineAccumulator lineAccumulator);
}

We did not start with this design but arrived at it when removing duplication and multiple responsibilities mercilessly ;-) The obvious implementation of ParagraphSplitter is to split on each blank, e.g.

class SeparateWordsOnBlanks implements ParagraphSplitter {

    private final LineAccumulator accumulator;

    // constructor omitted

    public void wrap(String paragraph) {
        for (String word : paragraph.split(BLANK)) {
            accumulator.addAndHyphenateIfNeeded(word);
        }
        accumulator.addCarriageReturn();
    }
}

which is not exciting at all. The heavy lifting is done by the accumulator which checks if adding the current word would exceed the maximum line length, invokes the hyphenation and adds blanks where needed. Whenever a line is complete it is rendered to the page.

class LineLengthAccumulator implements LineAccumulator {

    private final Page page;
    private final HyphenationRule hyphenation;
    private final int maximumLineLength;
    private StringBuilder currentLine = new StringBuilder();

    // constructor omitted

    public void addAndHyphenateIfNeeded(String word) {
        if (exceedingMaximumLineLength(SPACE, word)) {
            hyphenation.doHyphenate(word, this);
            return;
        }
        insertSpaceIfNeeded();
        appendToCurrentLine(word);
    }

    public void addWithoutHyphenation(String part) {
        if (exceedingMaximumLineLength(EMPTY, part)) {
            addCarriageReturn();
        }
        appendToCurrentLine(part);
    }

    private boolean exceedingMaximumLineLength(String separator, String word) {
        return currentLine.length() + separator.length() + word.length() > maximumLineLength;
    }

    public void addCarriageReturn() {
        if (currentLineHasWords()) {
            renderCurrentLine();
            lineFeed();
        }
    }

    // some private methods omitted

}

There are a bunch of unit tests using a NoneHyphenationRule or different anonymous mock rules to drive the functionality of the LineLengthAccumulator. For example

@Test
public void shouldNotWrap() {
    Page mockOutput = mock(Page.class);

    LineAccumulator accumulator = new LineLengthAccumulator(mockOutput, 78);
    accumulator.addAndHyphenateIfNeeded("This");
    accumulator.addAndHyphenateIfNeeded("is");
    accumulator.addCarriageReturn();

    verify(mockOutput).renderLine("This is");
    verify(mockOutput, times(1)).renderLine(anyString());
}

The HyphenationRule needs to know its accumulator and the other way round, which creates a conceptual cycle. Additionally we need a second method addWithoutHyphenation in the LineAccumulator to avoid endless loops during hyphenation. This is the result of following "Tell, don't ask" to the letter. Maybe HyphenationRule would be better off just returning the hyphenated word.

class SplitOnCamelCase implements HyphenationRule {

    public void doHyphenate(String word, LineAccumulator lineAccumulator) {
        if (foundAnUpperCaseLetterIn(word)) {
            String remainingWords = splitFirstSyllableFrom(word, lineAccumulator);
            doHyphenate(remainingWords, lineAccumulator);
        } else {
            lineAccumulator.addWithoutHyphenation(word);
        }
    }

    // private methods omitted
}

To unit test the hyphenation rules, a mock accumulator is used to verify the proper syllables.

@Test
public void shouldHyphenateWords() {
    LineAccumulator mockAccumulator = mock(LineAccumulator.class);
    HyphenationRule strategy = new SplitOnCamelCase();

    strategy.doHyphenate("ShortWord", mockAccumulator);

    InOrder inOrder = inOrder(mockAccumulator);
    inOrder.verify(mockAccumulator).addWithoutHyphenation("Short");
    inOrder.verify(mockAccumulator).addWithoutHyphenation("Word");
    verify(mockAccumulator, times(2)).addWithoutHyphenation(anyString());
}

I am pleased with our result, although it took us too long to complete it, which is a sign how much practice we still need ;-) See its full source code here. You might still find one or another thing that is not optimal and never will be but in comparison with my first version this Word Wrap expresses its problem domain more clearly and is easy to understand even without digging down into all the details.