Skip to Content

Changes for page Collective Ownership

Last modified by chrisby on 2024/02/27 16:05
From version 1.9
edited by chrisby
on 2023/10/13 12:51
Change comment: There is no comment for this version
To version 1.16
edited by chrisby
on 2024/02/27 16:05
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,7 +1,15 @@
1 -Code is collectively owned. Any developer can change any module at any time.
1 +Code is collectively owned. Any developer of the team can change any module at any time.
2 2  
3 3  ### Benefits
4 4  
5 -* **Improved Team Unity**: Eliminates factions and hierarchy.
5 +* **Improved Team Unity**: Collective ownership eliminates factions and hierarchy through equal access rights to the code.
6 6  * **Reduces Duplication**: Shared logic between different modules in the project through shared access.
7 -* **Balancing Specialization & Generalization**: While specialization increases productivity in a specific area, generalization fosters growth in technical knowledge and team support. Aim for a balance between the two. For example, a backend specialist may be responsible for a story that requires changes in both the frontend and backend. Ideally, the general knowledge is broad enough to solve the task, but if not, [[pairing up|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] with a frontend developer can be done to solve the problem and expand the frontend knowledge.
7 +* **No Bureaucratic Hurdles**: Not having to ask and wait for permission to apply constructive code changes saves time. In teams where there is no collective ownership, it is not uncommon for reasonable improvements to even be blocked.
8 +* **Module Responsibility**: It may make sense to have people responsible for specific modules, but they should only monitor changes, not block them.
9 +* **For big code bases, collective ownership may go across teams** like in an open source project, but company internal. Other teams create MR's and the team responsible has to approve it.
10 +
11 +### Specialization vs Generalization
12 +
13 +While specialization increases productivity in a specific area, generalization fosters growth in technical knowledge and team support. Aim for a balance between the two. Example:
14 +
15 +* A backend specialist may be responsible for a story that requires both frontend and backend changes. Ideally, the backend specialist will have enough general knowledge to solve the task on his own, but if not, he should be paired with a frontend specialist to solve the problem and expand his frontend knowledge. If the task is still too complex or difficult, the next options might be to reassign the task to another developer or get help from the team, and this decision should be made transparently and collaboratively by the team.