Collaboration on code is important. If we want to do Kick-Ass Software Development we need to get our changes fast, easy and without a big process into the code base and keep the code quality high. I start with 2 problems I’ve seen in software development teams.
Code collaboration problems
The indispensable developer
If you’re a developer that works just in your own codebase without anybody else touching your code, you are in a very unique position. You can commit code changes and apply patches for older versions without notifying anybody else. It’s just you, that have to know the code. But I’ve seen this behavior also when people work together in a team. Especially developers that are working for a long time on the project can have the tendency not wanting to share their code with the rest. These people do it because of two reasons: They are afraid that they got criticized and they want to save their job and position by making themselves indispensable. This person is a big risk for the company and destroys the team.
The control freak
In other projects you have one or two senior developers. They are so smart and they know the code that well, that every change by someone else needs improvement by them. The other developers in the team (let’s call them shitty developers) have to get their code reviewed by the senior people. If they reject their changes the shitty developers need to change the code again until it looks right in the eyes of the smart developers. Sometimes it takes over a week until a senior person can review the code. They have all tons of other more important stuff to do. You can indicate these “developers” easily when looking in their meeting schedule. Smells like a big unnecessary bottleneck to me.
Kick-Ass code collaboration
With Kick-Ass software development everybody can change every line of the code. There is no code ownership. When somebody sees a bug, he has to fix it. We share our code to learn from each other. We want to get our changes fast into the master with high code quality to start with the next code changes.
A branch for every task
We use the power of Distributed Version Control Systems like Git and Mercurial at Atlassian. We’ve implemented a simple workflow to avoid having a bottleneck in our development and move fast to the next task. Kick-Ass software developer create a branch for every task. With DVCS this doesn’t cost anything. When the task is done the developer can merge the changes back into the master branch. A task-branch doesn’t life longer than 2 days, so the change set for a branch is small and we can keep the overview. You don’t get lost when looking at the changes. This approach kicks ass because it’s fast, easy and it makes the developer to focus on a small set of work.
Don’t loose the power of CI
We’ve set up our continuous integration server to find all new created branches and apply the built plan automatically to the new branch. So we have an automatic build for each task branch. The developer doesn’t have to care about this. He just gets notified when he broke a test on his task branch. The CI server even deletes the plan automatically when there is no activity on the branch anymore. We even can do a built on a virtual merge: If our developers wants to find out if they will break the built after they merged the code back to the master they can do that without doing the actual merge. This helps us to avoid broken builds on the master branch.
Code quality and sharing with Pull Requests
What about code quality and collective code ownership when everybody can push changes to the master? Oooops, I forgot a detail here. Of course we’re doing code reviews. In Git code reviews are done with Pull Requests. The code author asks some reviewers for their feedback on some recent code changes. The changes are not very big (short living branches) so it doesn’t take long to go through the changes. The task based approach makes it pretty clear what the code change should do. If two reviewers are ok with the changes the author got notified and merges the code into the master. We normally pick three or four reviewers for a Pull Request just to avoid bottlenecks. Every “approve” counts the same, no matter if it was an expert or a newbie. The advantage that Git gives you over Subversion or CVS: You don’t have to merge the code before your code review has been approved. Your master stays always clean!
Kick-Ass Developer share code
The most important thing on code collaboration is the sharing part. We can learn from each other and we got to know all parts of the code base. Here are some points to keep in mind on Kick-Ass code collaboration.
- Kick-Ass Developer are happy to share code with others.
- Kick-Ass Developer are gentle to each other when commenting on other people changes.
- Kick-Ass Developer use automation to keep the code quality high and catch problems before they stop the whole team.
- Kick-Ass Developer trust each other that they won’t harm the code.
- Kick-Ass Developer can also communicate face to face when an online conversation takes too long
- Kick-Ass Developer don’t have complicated workflows or processes: branch – code – share – merge
Tools we use:
Sven Peters 