In my previous post I showed why exchanging the knowledge within a software development team is so important and I introduced first two practices we use to increase the knowledge transfer. Today I will present two more practices.
3. Pair Programming
I mentioned that we have used peer code reviews. While they are a very successful way of sharing the knowledge, there is a better way. We now find that pair programming with rotations gives much better benefits. If you do it properly, you don’t really get more advantages by reviewing the code separately.
So, how does it work?
We split the team into pairs. Every pair sits in front of one machine. One person writes the code, while the other reviews every single line of code written.
We often do it using ping-pong pattern - one person writes a single test and the other writes the code to satisfy this test, then people switch their roles.
Pair programming gives us a lot of lot of advantages, but writing about all of them would require at least a separate article. You can find a lot of information on c2 wiki.
In addition to a better code quality and other values provided by this XP practice, it gives us the knowledge transfer for free. You have a guarantee that at least two people know a given part of the code. Are two people still not enough? There is a solution - rotating people across the pairs. This allows the developers across the team to exchange the knowledge about the whole code base. Thanks to pair programming we not only share the information about the functionality, but also about the design, the code conventions and the best practices.
4. Self-Documenting Code (And Tests!)
Let's say you have to change some application behavior or explain it to one of the users. Unfortunately you are unfamiliar with this specific code or functionality (i.e. you were just assigned to this project). What's worse, all the other developers who are familiar with this functionality are currently busy fixing some major bug.
If you are used to work in a traditional environment, you will probably start searching for some documentation. If you are lucky, someone even wrote it. Unfortunately you will most likely find it useless, because nobody kept it up to date with the changing requirements and the changing code.
You won't find this kind of documentation in our projects, except maybe some high level architecture overviews. We don't like to spend the time on maintaining redundant documentation which, in order to be useful, has to be changed every time the functionality changes. This creates extra work and violates the 'DRY' (Don't Repeat Yourself) principle.
Instead we have something better - Cucumber user stories and RSpec specifications. By looking at the user stories, either a developer or a product owner should be able to immediately determine the currently implemented functionality. Specs allow us to understand the functionality in terms of the object behavior and object collaborations. The great thing about this approach is that our stories and specifications are a self-validating documentation. We automate them and run them continuously so they always reflect the current state of the implemented behavior.
We also believe that our code is our documentation and we focus on writing clean and readable code to achieve this. Among other things, we always try to create nice abstractions in our implementations, we use design patterns and we follow coding conventions. If we find that some code is too difficult to read or to maintain, we refactor it. We actually found that pair programming helps us writing better and more understandable code.
I'll describe some more practices in the next article.