Team code ownership lets any team member modify any part of the code. Ownership is an emotional or qualitative attribute that ties all developers on the team to the project and code base. It is a spectrum where, on one side, each individual has ownership of only their code, and on the other side, everyone on the team owns the entire code base. Some events appear to erode the team’s sense of ownership over the project’s duration, while some practices appear to counteract these erosions.
To increase productivity at Navyug, maintain craftsmanship of the code, keeping the developers motivated and involved we researched few papers and related them with our in-house case studies. Our finding was as follows:
Level of ownership is highest when developers:
i) they understand the product system context
ii) they have contributed to the feature/code in question
iii) they perceive code quality as high
iv) they believe the product will satisfy user needs
v) they perceive team cohesion as high
Product Context
For a team to work efficiently on any part of the system, at least one of them needs to know how that part of the system works end to end. Without enough context, one might struggle, slow down, or be blocked in working on a feature. Code ownership seems to vary with the context that the developer has to code about; the more the developer knows, the higher the sense of ownership. Knowledge silos, the increasing size of the code base, or the increasing/ changing number of developers working together can make a developer lose the deep context level understanding of the system.
Inability to contribute
A developer’s ability to contribute to the code base increases the developer’s sense of ownership. Whenever a pair programming breaks down, for instance, one person drives the code development while the partner passively watches. The participant ends up saying, “I cannot explain deeply what we have done, I cannot maintain it, I didn’t really write this, so I feel very little ownership of it”. Personally contributing to the code base increases a developer’s sense of ownership. As a developer works on the code base, the developer’s system context level increases. Developers might learn about the code changes from direct contribution, stand-up conversation or impromptu team discussions.
Pressure to deliver features and deprioritizing continuous refactoring
When developers are pressured to deliver more features at the expense of continuous refactoring, the code acquires technical debt, it becomes more difficult to work with, and developers can begin to feel indifferent about the code. Code apathy results in reduced quality, as the developers become less invested in the craftsmanship of the code. When code apathy settles in, team members adopt the attitude that someone else will solve the problem with the code and they can simply bolt new code onto the old one. When this attitude creeps in a team, no one is solving the problems and with time these decreases developers sense of team code ownership.
Product Definition Fitment
All engineers want to create products that solve problems for the user. Our balanced team approach works on collaboration between managers, designers, and developers. When managers or other stakeholders ignore feedback from developers or designers, the team can begin to feel less ownership in the product, and in turn, be less motivated to work on the project. Feature/ Product detachment can result in a poorly crafted product that does not meet the customer’s needs.
Team Cohesion
Few times we observed the team discussed code but never looked at the source code. One developer found these discussions difficult to follow. Sometimes the team discussed parts of the code that the individual had not seen recently. When the team discussed two variants of coding practices without sharing concrete examples, the developer could not contribute. When the developer raised this issue but still his team continued with the status quo, the developer felt marginalized by the team. Poor onboarding of developers can contribute to feelings of isolation. In one project, we were struggling with deadlines and the team was feeling the pressure to deliver stories.The team added more developers and left them all alone – “sink or swim” attitude, new team members felt very unwelcomed and sense of ownership reduced greatly.
Navyug found team code ownership highly advantageous, few agile practices including continuous pair programming, overlapping pair rotation, continuous refactoring, and test-driven development are also promising but fitment of practice is very much subjective from one product to another.