> 1. Strong code ownership breaks a code base up into modules (classes, functions, files) and assigns each module to one developer. Developers are only allowed to make changes to modules they own. If they need a change made to someone else’s module they need to talk to the module owner and get them to make the change. You can accelerate this process by writing a patch for the other module and sending that to the module owner.
I work on a team that supports about 2 dozen services, some with few modules, some with lots of modules. What happens when someone is sick or takes a vacation? How does what achieve coverage and competency unless there is shared ownership?
When new members are onboarded onto the team a lot of time is spent on building their competency in different domains and modules so they are able to be productive in different areas. We've also split the team several times to refine the domain and lessen the scope of what is needed for dev onboarding.
I think it is wise in many if not most companies to have strong team ownership of modules. Individuals are fragile.
1 comment
[ 2.0 ms ] story [ 12.1 ms ] threadI work on a team that supports about 2 dozen services, some with few modules, some with lots of modules. What happens when someone is sick or takes a vacation? How does what achieve coverage and competency unless there is shared ownership?
When new members are onboarded onto the team a lot of time is spent on building their competency in different domains and modules so they are able to be productive in different areas. We've also split the team several times to refine the domain and lessen the scope of what is needed for dev onboarding.
I think it is wise in many if not most companies to have strong team ownership of modules. Individuals are fragile.