This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October. Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til. Vi har lært en del ting om hva som i teorien skal være løsning:

Lately I’ve been thinking about how easy it is to fall into the trap of not challenging our ideas about the code we’re working on. In order to challenge the default mindset of Clean Code, I recently proposed to institute Dirty Code Monday (a proposal that sort of got me into a bit of a big discussion). Anyway, here is the report from the first successful Dirty Code Monday one week ago:

My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic. First learn to collaborate The most important skill we should teach is how to work well with others on a shared code base.

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others. When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa.

Less Overproduction (of unused functions in interface between team members) Less Waiting (for the only person who knows a particular area) Less Motion (as everyone gets more skilled) Fewer Defects (because two pair of eyes see better than one) Less Over-processing (from duplicate responsibility) Less Inventory (as team works on focused set of features and tasks) Less Transportation (handoffs inside a story) Less Underused talent (as everyone gets to share their skills)

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo. This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now? To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over.

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better. Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board.

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge. We practice pair programming to get redundancy.

When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming. Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied.

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this. I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session.

As it turns out, one of the least used practices of agile development is also one of the most powerful. Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I’ve experienced real pair programming, I never want to give it up. Pair programming offers benefits to many stakeholders:

Lately, I’ve been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I’ve chosen are: Java EE Spike: An application that stores People with names to a database and lets me search for them. I’ve repeated this pair programming with several different programmers. Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,… you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with “coconut”.

The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects. As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well.

People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode. The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling.