Remote Pair Practice

Deep in my notes of past conferences I keep a quote that says Writing code together is the only true way that programmers communicate. Even if you do not agree, pair programming is still a great way to share with one another. Whenever I program in a pair, I learn a lot. Unfortunately I have a very little opportunity to do so as my team is distributed around the globe. After attending a Test Driven Development workshop at this year's GeeCON I decided to do something about it.

Schedule
I plan for a pair coding activity each week. This seems like a good target to aim for. To free one or two hours each week for deliberate practice should be possible for everybody. Unfortunately I do not reach my target because I might be busy, might still look for a pair or my pair might be busy as well. In the past I only managed to participate in a pairing session twice a month. By writing this post I hope to save time on explaining and to improve the frequency of my pair programming. I found it better to schedule throughout the day instead of the evening. It also seems easier to find a suitable time at work days instead of weekends. Keeping away from evenings and weekends helps because there are still people with some private life ;-). An appointment at a fixed day and time is an option when pairing with the same person again and again, but to meet with different people, one has to be flexible. I do not care for the time as long as it is somewhere in my (European) time zone. To find suitable times in advance I use Doodle.

Pair Programming
A lot of people are afraid of pair programming because they never did it. To get started you should read James Shore's description of Pair Programming from his book The Art of Agile Development. There is even a short summary consisting of 99 words for the people who do not have time to read. In the end the rules how to behave during pair programming, are about practising everyday civility, because all I really need to know about pair programming I learned in Kindergarten. So be especially courteous. Pair programming teaches us to collaborate. I recommend watching Angela Harms' presentation about the (social) anti patterns in pair programming, Does pair programming have to suck? Note that pair programming may be difficult and uncomfortable for the first few times.

Get-Together
Obviously we have to meet in order to pair. In the past I managed a few times to meet during lunch breaks and have a short pairing session, much like Code & Coffee. Now I always bring my laptop when I meet my friends for lunch, maybe he is interested in a spontaneous pairing session while eating?

Remote Setup
Meeting in person is preferable but not always possible. Remote pairing is mainly about the additional tooling and all rules from regular pairing apply as well. My friend Thomas wrote a good post about Pair Programing from which I took all the material of this section. We use Skype to talk and TeamViewer to share our screens. It helps to have Skype contacts exchanged in advance so one can start the remote session by sending a chat message to the other one. As soon as the line is established we discuss who will host the session. A good headset is recommended, otherwise the voice quality is poor.

Then the host starts his TeamViewer and sends his TeamViewer id in Skype. I never had any problems with TeamViewer and it works great, even when connecting Windows and Mac machines. TeamViewer is a commercial tool but free for non-commercial use. A pairing session is definitely for educational purposes, so I do not see any problems with the license. After connecting I recommend changing the resolution of the host machine to the maximum resolution supported by the client. As a client I use TeamViewer's options View > Original and and View > Full Screen to get rid of all these scroll bars. If I have an additional screen I put the Skype window and a browser window there, if I want to look something up quickly. This setup is much like Level Four Pair-adise, except that it is remote.

It happens that I would like to scribble something on a white board. There is a nice Web Whiteboard, which allows drawing and shared editing. It is as simple as a real white board. If you need something more advanced, create a new Scribble in Google Docs which allows shared editing as well. All these and even more advanced topics of remote pairing are discussed by Joe Moore in his excellent talk about Remote Pair Programming: People and Technology.

Code Kata
An educational pairing session looks much like a Coderetreat. We might do a code kata or whatever coding problem seems adequate to work on. A code kata is an exercise in programming which helps a programmer improve his or her skills through practice and repetition. When I meet someone new, I do not impose any special rules. We would just work on a kata, preferably one that we both know, using ping-pong styled Test Driven Development. Todd Sedano compiled a list of code katas sorted by how easy it is to apply TDD. Fizz Buzz and Prime Factors are too short, but all other katas beginning with String Calculator are suitable. In fact the size of the kata does not matter, because it is not about finishing, it is about improving.

The choice of programming language is not important to me. Although my primary language is Java, I have done katas in Ruby, Scala, JavaScript and C# as well as some other, less common languages. After choosing the kata, the language and the development environment to use, we need to agree on the focus of the training session. There are some variations of katas possible, e.g. to use a more functional programming style or not to us any primitives or conditionals, up to the (at least for me) extremely difficult TDD as if you meant it.

With Tomatoes
It happened that we would lose track of the time while focusing on the problem. Later, for example after working on the kata for two hours, we would "wake" up and be totally exhausted. To prevent this, and to create some space for chit-chat, I use the Pomodoro Technique. There is a break of 5 minutes every 25 minutes. I just watch out to stop the Pomodoro with a failing test, so we know where to continue after the break.

Conclusion
As shown my remote pair practice contains everything that is good and holy: pair programming, cool tools like video conferencing and screen sharing, coding, TDD, code katas and Pomodoros. Can you resist?

Code Cop Kofler

Summer began last month in Austria and I went abroad and got myself a lovely souvenir: a carved wooden desk name plate. I was not sure what to write there and thought about my twitter name but did not trust the artificer to cope with the @-sign and ended with some kind of hybrid name:


In hindsight I was clever not to ask for something complicated because the guy messed it up twofold and did not even get the letters of my name right. Nevertheless it is an icon of my office and I love it. If only I had a desk to put it on.

My Open Source Involvement

My current employer is refreshingly serious about software licenses. For example if an open source library is GPL licensed, it just cannot be used in a product or service offering. End of story. All other companies, I have ever worked for, just did not care. I like being serious about software. But it is not just about using the software, in fact it is about being contaminated with someone else's intellectual property, whatever this might be. To comply with my employer's bureaucracy I have to report my open source involvement and get written permission from my manager. Ok, so let's collect all my active open source projects and list them here as well. Some advertising never hurts.

• It began with PMD (BSD License), a source code analyser for Java, which I used a lot. In 2004 I started submitting patches and later I created my own set of custom rules as Maven module. Unfortunately the new PMD 5.0 is not backward compatible, so I have some pending work to do here. (Source Code)
  
  
• In 2008 I created a system tray notifier to monitor build servers under BSD license. I use it myself and have to create maintenance releases from time to time. (Ah delicious dog food ;-)
  
  
• javaclass-rb is a Java class file parser in Ruby. I created it in 2009 and I there is a small release once a year. Although it is not finished, it is particularly useful to analyse custom Java code. I hope that I will have some time in the future to describe it in detail.
  
  
• Since last year I am organizing Hackergarten Vienna. Hackergarten is a craftsman's workshop, a classroom, a laboratory, a social circle, a writing group, a playground and an artist's studio. We meet once a month and work on Open Source. During this time I have submitted patches with working code to Commons Exec, Castor, Commons Email and JMeter (all under Apache License).
  
  
• My latest project is BaDaDam, an experimental BDD framework for Java. It allows you to write stories in plain text, implement them in Java classes and just run them using JUnit. Some people from Hackergarten have helped me with contributions.
  
  
• Occasionally I submit pieces of code to Rosetta Code, a programming chrestomathy site.

T-shirt Update

I love t-shirts and keep wearing them regardless of my employer's dress code. I had only two complaints about them in the last year, so things worked out quite well ;-) The last time I wrote about Code Cop t-shirts was more than two years ago, so it is definitely time for an update.

Don't Repeat Yourself
The Don't Repeat Yourself or DRY principle states that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. In simple terms this means that there should be no duplicates or repetition. The dark blue DRY shirt reminds me to write things once and only once. It is also my best selling shirt ever, as a friend bought one after he was exposed to horrible duplicated code at the client's site. Unfortunately I did not get rich as I bought him a beer in return.

Keep the bar green to keep the code clean
Keeping the bar green is the primary motto of JUnit, the popular unit-testing framework for Java. This grey shirt displays a simplified image of the Eclipse JUnit runner together with a green bar. I had problems finding the right dimensions for the characters and the green check marks and threw away at least three versions until I got it right. One day I wore it in the office and one of my colleagues, a project manager, asked me "green is good, right?" I just love them.

Red-Green-Refactor
Red-Green-Refactor is the cycle of Test Driven Development. You write a failing test which results in a red bar. Then you write some code until the bar is green. Finally you clean up the code you just wrote, e.g. improve the names or remove duplication. (Remember DRY?) For the white shirt I used typefaces according to these phases: Red is scary, I do not like it, so I used a Halloween typeface for it. Then I go for a green bar as fast as possible, so I used a dynamic typeface for that. My result after refactoring is sorted and tidy symbolized by a regular typeface.

(Buy Code Cop shirts)