9 Tips for Collective Ownership and Clean Code

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.
If you’d like a free consultation about Collective Ownership, please leave your email address.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  • Ardee

    “Don’t use an author tag” – now I was not aware of implications when doing this. Used to make this often, as sort of developer pride or feeling that I have contributed something. Now not adding it or removing it makes sense.

    • Alain F

      That is actually a very interesting discussion by itself. I have had this discussion with one of our clients, and will actually create a blog about it. One important book for developers “The pragmatic programmer” actually ends with “Signing your code”.

  • Benj Medina III

    I am thankful for learning about these tips right from the start. By consistently putting these into practice, I know that at the end of the day I am always able to write not just a code that complies with the requirements but also a code that is testable and easy to maintain.

  • Jeric Cariño

    Programming languages, technology frameworks, and coding tools: they may change rapidly. But these best practices ought to be carried over consistently across any and all projects. Great article!

  • Pingback: You_Source 2 Tips to Reduce the Cost of Your Software Development in the Long Run()