How We Apply Collective Code Ownership at Nulogy
Introduction
At Nulogy, we practice Collective Code Ownership: everyone in the team is responsible for all the code and anyone can change any part of it. Collective Code Ownership is difficult to implement. However, it yields many benefits:
- Reduces risk in a project by increasing its Bus Factor.
- Speeds up the development process because any programmer can pick up the next task or defect.
- Improves developer skills as they get to work on any part of the software from the database to the UI.
- Yields a cleaner codebase because any developer can improve any part of it.
Implementing Collective Code Ownership is challenging because developers have to work on code they did not write. In this post, I will describe the practices we follow that make Collective Code Ownership work for us.
Pair Programming
All engineering teams at Nulogy use Pair Programming. Pairing is a very effective way to distribute the knowledge on how the application works. To make sure the knowledge is well transferred, we often switch pairs (at least every day) and switch drivers (several times during the day). It sounds a little scary when pairs are switched in the middle of a task, and to make sure the new developer gets full context quicker on the ongoing task, we let them drive right away.
Also, if you are going to work on unfamiliar code, makes sure you pair with an expert on that part of the code, and that you drive most of the time.
Even though we pair on the same desk, some pairs still use a screen sharing application like Screen Hero or the Screen Sharing app from OSX. On my team, each desk has 3 external monitors, 2 are used by the driver and 1 by the navigator.
Code Reviews
When a team has more than one pair, code will be merged before everyone in the team has a chance to work on the new code. This is why, to better diffuse the knowledge, teams at Nulogy also perform code reviews. This is particularly important when starting a new project because developers are building the framework and infrastructure for the new application. Another benefit from code reviews is that code is improved as the reviewers comment ideas and point to errors.
On my team, code reviews normally happen at the end of a task, when the source control branch is ready to merge to master. We have the column “Review” on our Kanban board where we place tasks that are ready for review. We also create a Merge Request on Gitlab where other developers can write comment on the diffs. The requirement is that at least one developer with less involvement on the new code should review it and give a LGTM (Looks Good To Me). Once all the comments and discussions on the ticket has been resolved, and our Gitlab CI for the Merge Request passes, the reviewer can Accept the Merge Request and merge the branch via Gitlab.
Code Consistency
We value code consistency. It makes code more readable and removes the need from the developers to constantly make decisions about what quotation to use for strings, how to indent case statements, what style of Ruby hash to use, etc. By having an explicit set of rules on how to write code, less time is spent discussing what style should be used on every line.
We start a project with very strict linter rules and loose them a bit as we find rules that do not fit our project or culture. Having code consistency across all the code base means the team agrees on a coding standard, and therefore, making collective code ownership easier.
To lint Ruby code, we use Rubocop. It has a lot of community support and it can auto-correct your code when it violate some of the rules. We also use the RuboCop RSpec extension.
We lint JavaScript code using eslint and eslint-plugin-react. These linters have helped us stay away from old ES5 bad habits and use good styles for writing React components as some of us were new to these technologies.
Lastly, we use sass-lint for our sass files which helps a lot on having clean style files in our project.
We run all our linters as part of our test suite and the Gitlab CI, and make sure they all pass before merging new code to master.
Clean Code and Simple Design
Readable code also helps with collective code ownership. Self-documenting code is very important. Be consistent when naming variables, methods and classes, and use ubiquitous language. Remember that the code should be readable not only by you, but by the whole team.
Code is written once and read many times, so we optimize for readability. We use descriptive names, small classes and functions. We follow an Inverted Pyramid style which helps developers new to the code understand what classes and functions are doing without reading all the details.
We avoid speculative coding. We remove code that’s no longer in use. We eliminate duplication.
Doing all these things is essential to achieve clean code and simple design.
Good Test Coverage and TDD
Collective code ownership is dangerous without good test coverage. Well written tests serve as documentation for the code. They also help to validate assumptions about the code and protect against introducing bugs. We feel way more comfortable changing unfamiliar code when there is a suite of tests backing us up. On top of that, good test coverage helps my team achieve clean code, since refactoring is less likely to introduce regressions.
At Nulogy, we believe the best way to achieve good test coverage is by practicing Test Driven Development (TDD). It allows us to move faster. It gives us confidence that the team is always delivering good quality software. By using short TDD cycles, and starting with a failing test, we validate all code we write is tested. It also pushes us to use simple design since simple design will make tests easier to write.
Another tool we use to verify we have good test coverage is simplecov.
Conclusion
By practicing Collective Code Ownership, teams will build sustainable products. Any developer in the team will be making improvements to any part of the codebase. When the composition of the team changes or anyone takes vacation, the team will keep its velocity.
