Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you handle code ownership?

news.ycombinator.com

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Ask HN: How do you handle code ownership?

#61

Post by breischl »

mirceal wrote: post #53
breischl wrote: post #31

Earlier quoted context omitted.

That works OK-ish for small organizations. When you have 1000 engineers, or even 100, it is no longer feasible to have a single on-caller who can keep up with changes enough to debug every system, much less the multiple on-callers you need in order to have an on-call rotation. IME even in small organizations (<20 engineers) it's very easy to end up not knowing enough to debug everything, and your on-caller basically…

nope. you need to know how the thing that you're responsible for works. no exceptions. what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service ca…

>owners for services if okay

This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit:

>once you submit the code for review and it passes and gets merged everybody owns the code. Everybody.

Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree.

>you need to know how the thing that you're responsible for works Agree with this as well, but a critical point is that "the thing you're responsible for" may be subset of "everything" in your organization. Maybe even a relatively tiny subset, in a large organization.

Re: Ask HN: How do you handle code ownership?

#62

Post by spc476 »

The office I work in has five development teams that cover different aspects of our service (provisioning from our customers, core product on Android, the UI for the Android code, servers, and call processing [1]). Each team has ownership of their respective products and how things are divided up are left to the teams themselves.

The team I'm on has three developers (I'm one of them) and for our team, we just kind of fell into ownership of different aspects. I deal with the programs that are customer facing (CDMA and SIP interfaces); the second developer deals with the business logic (a separate program) and the third deals with SMPP (also customer facing, but not as critical as the CDMA and SIP interfaces). And it's not like we (my team) are fiercely protecting our turf (each of our programs)---I have worked on both the business logic and SMPP service, but generally, each of us just gravitated to what we find enjoyable.

I do not know how the other teams divide their work.

Bug reporting is pretty each to route as each portion of our service is clearly delineated (with the possible exception of the Android core and UI teams).

As far as features go, it depends upon the feature. Yes, there are some features that affect all the teams (such as number to name translation---have to provision that, deal with obtaining the info during call processing and having the phone receive and display such information) and some that only affect one department (like supporting SIP---largely my team).

[1] I work in the call processing side of things.

Re: Ask HN: How do you handle code ownership?

#63

Post by scarface74 »

macca321 wrote: post #45
scarface74 wrote: post #9

Earlier quoted context omitted.

The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment. I have just the opposite problem. No one else wants to add features to code that I wrote because they don’t want to ramp up. This isn’t difficult to understand code - some of it is less than a 30 line Python AWS Lambda function. The process is documented in the repo in the readme.

What's tricky is when that lambda doesn't have a documented contract with the systems it talks to, doesn't have end to end integration tests, has a unique build pipeline, requires manual infrastructure creation and there are 100 others like that. I'm not saying yours is like that, but I've definitely seen that happen.

Well, many things on your list are spot on but the ones that are shouldn’t be scary.

- end to end integration tests - if they are APIs, they for the most part have a Postman collections in the repo. If they are event based lambdas, they have the standard

  if __name__ == "__main__":
Code that calls the handler with dummy data.

- build pipeline and manual resource creation. It’s so easy to export a SAM template from the console it’s criminal to not at least do that. But, yeah we have a CodePipeline to do that.

I have been on the other side though of inheriting a lambda and wondering how the hell did they go through the write->debug->fix cycle? Did they actually load it to AWS first? I spent a day creating a “test harmess”. Not real AAA unit tests, just something I could run locally to debug.

Re: Ask HN: How do you handle code ownership?

#64

Post by rufius »

snidane wrote: post #47
rufius wrote: post #24

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…

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?

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.

Re: Ask HN: How do you handle code ownership?

#65

Post by mirceal »

breischl wrote: post #61
mirceal wrote: post #53

Earlier quoted context omitted.

nope. you need to know how the thing that you're responsible for works. no exceptions. what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service ca…

>owners for services if okay This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit: >once you submit the code for review and it passes and gets merged everybody owns the code. Everybody. Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree. >you need to know how the thing that you're responsible for wor…

yes. everybody in the team. i sure hope there aren't places out there where you have thousands of people each responsible for millions of lines of code.

my point was that you should not have individual code ownership and individual gatekeepers. I can see how that might be misinterpreted.

Re: Ask HN: How do you handle code ownership?

#66

Post by stunt »

Ideally you want to restrict changes to the owners (I don’t mean hard limits) So instead of having a team responsible for a part of code, they are responsible for the product. So if a new integration is needed, the owner is a service provider and should provide the interface or service for their client. That is fairly easy to setup with Microservices. However, that is a bit harder in a monolithic application code base.

In my workplace, we use the above model for almost everything. And there is one old code base where we use Github code ownership feature to force everyone to ask for a code review from owners. But even there, it doesn’t happen very often that people from different domain need to touch a code of another domain.

And that is the second point as well. Dividing responsibilities base on domains instead of components/modules between teams make it easier as most of the time they are not going to touch a code outside their own domain.

Re: Ask HN: How do you handle code ownership?

#67

Post by WorldMaker »

elpakal wrote: post #56
gwbas1c wrote: post #40

Earlier quoted context omitted.

Github has the code owners feature. A pull request can't be merged until all the owners approve.

and what if you don't use GitHub?

One option is that the feature is built on a plain text .gitignore-like (.gitattribute-like more accurately) CODEOWNERS file(s) in a repository that you could implement support for in whatever tools that you do use.

https://github.blog/2017-07-06-introducing-code-owners/

Re: Ask HN: How do you handle code ownership?

#68

Post by externalreality »

mharroun wrote: post #6

- Ceartian people own certain systems/projects. - Ownership is only the point person of knowlage/direction/insights - Anyone can work on the code "owned" by someone else - Idealy the writer fixes their own bugs and does their own refactoring (for speed and learning reasons) but that should NEVER obstruct delivery of a feature or value add to the company. The moment a team starts pointing fingers for issues or starts…

I do believe in giving people responsibility for an area/concern/system of code. It gives them a sense of responsibility and and encourages them to do good work. It allows some creativity and style. I limits turn-over. I agree with totally however.
Post reply on HN