This is the first post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
In free jazz, improvisation is an important part. But the musicians don’t just play whatever they like. If the Saxophonist takes over from the Trumpeter, he (normally) takes over a little part of the melody and then starts to modify it.
We should build software the same way in our team. We should build upon what is already there.
Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about pair-programming, there is a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software.
Let my show you why this is wrong.
Over the last couple of years, I’ve done a lot of pair programming. Pair programming inside my team, at customer sites, in coding dojos and in my open source projects. Pair programming is really a great and effective experience when performed by an pair of developers knowing how to pair program. Unfortunately, you cannot just put two developers in front of a single computer and expect them to perform perfectly from the start. Pair programming has to be learned. Both developers need to learn the...
Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.
Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.
To get most out of pair programming, you first have to know your setup.
These are the slides and comments of a presentation I held for bbv Software services AG. The presentation is about how we get quality into our code. Buzzwords: Fokus, frequent measurements, strong team, clean code, pair programming, test driven development, acceptance tests, continuous integration, collective code ownership, team learning. Urs Enzler Senior Software Architect bbv Software Services AG urs.enzler _at_ bbv.ch (replace _at_ with @) www.bbv.ch Copyright © 2010 bbv Software Services...