3 ms·

In our case, teams don't own projects/code-bases, they own "features" and "releases". About 67% of our code is some form of Ruby - some of it Rails, some of it

by rufius 7y ago

In our case, teams don't own projects/code-bases, they own "features" and "releases". About 67% of our code is some form of Ruby - some of it Rails, some of it custom Ruby code running in Kubernetes+Docker processing data. The other 33% of our code is Rust - and not just service side code but Rust that has to run on multiple platforms with varying deep operating systems knowledge. My team generally owns Features and Releases related to the Rust code because two of the three members are OS programmers by experience. That said, we don't exclusively work on the Rust code and sometimes wander into the Ruby code base. Similarly, other teams occasionally need to update the Rust code to generate some new data - a lot of that is pretty basic stuff and doesn't require deep OS knowledge. So they'll make changes there. Since our stack is so heterogenous, it's hard to have everyone work on everything. However, from what I know of most companies outside Apple/MSFT/Google/etc, they're gonna fall in the "we own web services" where the only real bifurcation will be "frontend code" and then "middle-to-backend code". Maybe throw in some apps as well. ========= Now all of that said - the reason we went to teams owning "features" and "releases" was to push folks to not be possessive of code. Stuff changes and it changes quickly, so there's not much use trying to isolate folks. Document gratuitously, test heavily, and refactor often.

snidane 7y ago
I like the idea of owning features and releases. This lets the team to assign a responsible person for documenting and demoing the new feature or release. How do you respond to emergencies when your people don't own projects or code bases? Who gets woken up at midnight? The person responsible for the latest release? Wouldn't that discourage people from deploying new releases?
- rufius 7y ago
  SRE + On Call Dev Engineer. Basically SRE takes the page - if they can't troubleshoot it or restore it to normal service, then the on call engineer gets called. In our case, we're still small enough that one on call engineer has to take the load regardless of feature/product. The exception is the aforementioned Rust code base which calls myself or the other engineer. But this is because it's not running on our infra - it's running on customer boxes so that's a different support story. Re: > How do you respond to emergencies when your people don't own projects or code bases? Who gets woken up at midnight? The person responsible for the latest release? Wouldn't that discourage people from deploying new releases? Culturally, our engineering team doesn't really tolerate "not deploying". That's not to say that you're being measured by number of deploys like some sort of perverse "IBM Lines of Code" metric - but you're expected to be deploying code as it's ready via PR + Tests. It's not a perfect system but we've tried pretty hard during hiring to select folks that are well aligned with how we think about this. No one gets to own their space and no one is immune from rolling their sleeves up and figuring it out. If that isn't someone's thing, we try to find that out during the interview because it doesn't fly internally with the team.

by rufius 7y ago

snidane 7y ago

I like the idea of owning features and releases. This lets the team to assign a responsible person for documenting and demoing the new feature or release. How do you respond to emergencies when your people don't own projects or code bases? Who gets woken up at midnight? The person responsible for the latest release? Wouldn't that discourage people from deploying new releases?

rufius 7y ago
SRE + On Call Dev Engineer. Basically SRE takes the page - if they can't troubleshoot it or restore it to normal service, then the on call engineer gets called. In our case, we're still small enough that one on call engineer has to take the load regardless of feature/product. The exception is the aforementioned Rust code base which calls myself or the other engineer. But this is because it's not running on our infra - it's running on customer boxes so that's a different support story. Re: > How do you respond to emergencies when your people don't own projects or code bases? Who gets woken up at midnight? The person responsible for the latest release? Wouldn't that discourage people from deploying new releases? Culturally, our engineering team doesn't really tolerate "not deploying". That's not to say that you're being measured by number of deploys like some sort of perverse "IBM Lines of Code" metric - but you're expected to be deploying code as it's ready via PR + Tests. It's not a perfect system but we've tried pretty hard during hiring to select folks that are well aligned with how we think about this. No one gets to own their space and no one is immune from rolling their sleeves up and figuring it out. If that isn't someone's thing, we try to find that out during the interview because it doesn't fly internally with the team.