Collective ownership encourages everybody involved to contribute new ideas to all segments of the project. As a project owner, collective ownership should be one of your primary goals. Although we developers take pride in being a species apart from the rest of the human population, developers are not very different from other people in the sense that nobody likes to clean up other peoples mess. For one it’s hard to follow the trail and it’s hard to rebuild something when it’s already broken at the very start.

Plenty of IT projects have failed because there is no sense of collective ownership. People tend to rely on the person who “authored” the class and no one feels the need to step up even when they can.

Here are 9 tips you need to remember to create collective ownership and cleaner code:

1. Don’t use an author tag in the header documentation of your classes. Other developers may not feel responsible to maintain the class, and will not easily invade the author’s territory. If you want to know who wrote it, you can find this in the history of your source control system!
2. Unit testing, unit testing unit testing. Let me repeat that one more time: Unit testing. Testable code equals maintainable code equals high quality code. Nobody wants to leave behind poor code in a well-designed and written system. Also, when a system is properly tested, it gives the developer confidence to change code when all the tests still pass. Also, tests can act as an example on how code is intended to be used and will help avoid code duplication.
3. Invest in a proper Continuous Integration (CI) process, and let part of the process be to ensure that 100% of the tests pass. Do not accept anything less.
4. Plan for periodic code reviews. The fact that code reviews will take place will make the developer think twice about leaving poor code in the system, even when the deadline comes close. On top of that it has the added benefit that the reviewer(s) learn more about the way the system is implemented and it is a great way to help juniors how to code better.
5. Use tools like StyleCop for automatic code reviews. Although StyleCop will not help you implement the code smarter or better, at least all your code looks and feels similar. Again this contributes to the collective ownership as it is very difficult to tell from the code who actually wrote it, so everyone will actually feel responsible for it.‍
6. Apply the Boy Scout rule. Whenever classes need editing, make sure to leave the class in a better state than it was before you edited it. Add an example to the documentation, or remove the unused private method. Increase the test coverage by adding a missing test. There is always room for improvement.
7. Follow the SOLID principles where applicable. Code that follows these principles is more maintainable, easier to test and easier to extend. Make sure not to over-design and follow the rule of 3.
8. Stay DRY (Don’t repeat yourself). Code duplication is the root of all evil.
   Agree with your team about placement of code. Placing code in the wrong location may lead to code duplication or perhaps even implementing the same functionality twice.
9. Agree with your team on the CQS (Command Query Separation) principles. Code only changes state on a command, and not on queries. Consistency is key.

‍