Don’t be overprotective of your source code. Allow others to make modifications, improvements, refactorings, and even defects (as long as those get fixed immediately). I am talking about two different Extreme Programming practices here: collective code ownership and pair programming. A non-developer friend of mine has been reading about agile software development and asked me last week about pair programming, "do you guys do this 'pair programming' thing?"
I think even among developers the pair programming concept is one of the strangest aspects of extreme programming.
Yes, a lot of agile development teams use pair programming. We even equip our facilities to make pairing easier. Our computers have 2 large monitors, 2 keyboards, and 2 mice. Some teams pass the keyboard and mouse back and forth, and that works just as well.
What is Collective Code Ownership?
This is a great term that basically says that every member of a team should be able to work on any part of the system. If you’re usually working on the user experience you can still spend some time working with your application’s service layer, and if you’re the database guy you can work on some business logic.
Wouldn’t someone be able to do that job better? Yes, there probably is someone who knows each part of the application better than anyone else. You can work with that person if you want, and the two of you will be able to create some great code. What if that person who is better at that task is on vacation? Wouldn’t it be great if someone else knew the code.
Keeping the team familiar with the project means that the team can focus on certain parts of the system at a time and achieve great results. You don’t have to split your team based on layers or modules of your application. Let them intermingle. Fresh ideas and eyes can greatly improve things. They might come along and fix a defect or two for you later; saving you a great deal of work.
Why Pair Program?
The mind is the important part of programming, so why not have two? After all, programming is certainly not just typing. If you believed that how could you ever support pair programming?
If you pair program for every line of code in your application then you know that you’ve had at least two sets of eyes look at every line of code. This is a good deal of added security.
When you create some new piece of code that the whole team will need to work with, pair programming can be the solution to disseminating this information. You and the guy you created it with can split up and pair with another person each, and while working on the code you will each be showing your new partner how the new code should be used. This allows new information to spread quickly through the team.
Even the simplest things as learning keyboard shortcuts are improved by pair programming. When I use a cool keyboard shortcut, I can tell my partner what it is without breaking my train of thought. We can keep on typing, and when he has the keyboard in a minute or two, he can try it.
Just like athletes, a programmer needs someone else there to help him keep the pace. You partner can help you avoid distractions, and most importantly he can keep you from taking shortcuts. When we write code we might say, “I can fix this later”. The partner will make a note of it and be sure you get it fixed later. If it can’t wait and you’re in the middle of something you can always pass it to another pair. Your partner can do that while you keep on coding. Remember that the other pair can work on any code because of the collective code ownership.
I am sure I missed plenty of reasons to pair program, but this list feels mostly adequate to get the point across.
Please let me know why you do or do not pair program. Is it work related? Are you an unbeliever?
Comments