3 ms·

The weight of having to support what you write is an important one for a developer IMHO. It is easy to slap together crap and toss it over the wall as good eno

by ilc 3y ago

The weight of having to support what you write is an important one for a developer IMHO. It is easy to slap together crap and toss it over the wall as good enough, and then, the "hone team" is stuck with supporting it. For example: Imagine building the feature on a O(n^2) data structure, it'll work fine to start, but long term, we'll need a O(log(n)) structure. I wonder who has to do the work on the "slow performance" bug, and data migration. These concerns aren't abstract. They are very concrete. There will be landmines left behind. Even when we try not to leave them behind we do as developers. Without responsibility... it would be even worse. This is also why I don't like having one team do all the Greenfield work, and one do all the fixing.

softwaredoug 3y ago
I much prefer an “operating system” model. The away teams should be writing “userland” code within the home teams well defined guardrails. The home teams act as OS devs for their service mostly write “kernel” code for their service that empower the away teams. Usually the “home team” are functional specialists. They are working on some piece of infrastructure or maintaining a service. The “away” team OTOH is building a feature and needs to touch a few dozen codebases It should be obvious which code is kernel and maintained by the service team, and which by the away “app” team. The away teams should be maintaining, on-call, and responsible for their code running within the context of the home teams service. Which hosts many such “apps” https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fail.html https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fai...
- flaminHotSpeedo 3y ago
  It's painfully obvious you've never been on either end of this problem. In big orgs, if you have time to set up baby fences (or had them from the start) you have enough free time to build the feature yourself. No one who hosts an away team is prepared to do so
  - pfannkuchen 3y ago
    I have successfully done this repeatedly in a very big org, though it wasn’t easy and it also wasn’t at Amazon.
  - softwaredoug 3y ago
    Yes I may be an idiot, though this has worked well at several places. For example, this worked really well for us at Shopifys Discovery team at for moving fast on search relevance and recommendation systems. To clarify how to build and test search experiments really fast. I would say it’s the default model/culture at Shopify. (Not away team per-se but more the “OS” model)
    - flaminHotSpeedo 3y ago
      Sorry, I was more aggressive than I should have been. I misunderstood your comment, I thought you were suggesting the home team build the guard rails in response to another team's request. I don't disagree that the pattern you're describing can be effective if the home team was always expecting other teams to work in their codebase. But that's not what the away team model is, the away team model is for unexpected cross team work. E.g. if the guard rails are too restrictive and the home team doesn't have time to expose the new functionality to "userland" code so the other team needs to work with "kernel" code to do so.
      - softwaredoug 3y ago
        No worries :). What I suggest I think is different than away team (which feels a bit like swoop in and crap on host teams codebase). Just saying I prefer it to away team. Fundamentally it’s just a hard problem most large orgs don’t do that well
ramraj07 3y ago
This problem is mitigated if we assume competent engineering teams on both sides - the away team shouldn’t merge code without proper review of the code by the owner, for one, and the away team should go above and beyond in being diligent about code quality, QA and understanding the codebase to the core before changing it. Thus the away team(s) should consist of the best engineers in the org. That’s my read anyway.
- NBJack 3y ago
  That's definitely not how Amazon works. The most successful engineers there never stay in one place for long. This, plus the perpetual burnout due to things like Away Teams and S-Team goals, means you will instead have a revolving door of talent and fresh hires.
barbariangrunge 3y ago
I was just thinking this. The home team loses some control over their architecture and might gain tech debt this way, especially if different teams have different development philosophies and preferences. Plus, you lose a ton of time implementing features outside your area. Your away team didn’t know that those 5 functions had to happen in order, due to a timing issue nobody could figure out, so your code to change how a panel animates is now breaking unrelated calculations somewhere and causing data loss. You blame the home team for having bad architecture, but then learn a different group of three different away teams set that up and nobody can figure out how to clean it up because of the ripple effect bugs. There be dragons

by ilc 3y ago

softwaredoug 3y ago

I much prefer an “operating system” model. The away teams should be writing “userland” code within the home teams well defined guardrails. The home teams act as OS devs for their service mostly write “kernel” code for their service that empower the away teams. Usually the “home team” are functional specialists. They are working on some piece of infrastructure or maintaining a service. The “away” team OTOH is building a feature and needs to touch a few dozen codebases It should be obvious which code is kernel and maintained by the service team, and which by the away “app” team. The away teams should be maintaining, on-call, and responsible for their code running within the context of the home teams service. Which hosts many such “apps” https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fail.html https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fai...

flaminHotSpeedo 3y ago
It's painfully obvious you've never been on either end of this problem. In big orgs, if you have time to set up baby fences (or had them from the start) you have enough free time to build the feature yourself. No one who hosts an away team is prepared to do so
- pfannkuchen 3y ago
  I have successfully done this repeatedly in a very big org, though it wasn’t easy and it also wasn’t at Amazon.
- softwaredoug 3y ago
  Yes I may be an idiot, though this has worked well at several places. For example, this worked really well for us at Shopifys Discovery team at for moving fast on search relevance and recommendation systems. To clarify how to build and test search experiments really fast. I would say it’s the default model/culture at Shopify. (Not away team per-se but more the “OS” model)
  - flaminHotSpeedo 3y ago
    Sorry, I was more aggressive than I should have been. I misunderstood your comment, I thought you were suggesting the home team build the guard rails in response to another team's request. I don't disagree that the pattern you're describing can be effective if the home team was always expecting other teams to work in their codebase. But that's not what the away team model is, the away team model is for unexpected cross team work. E.g. if the guard rails are too restrictive and the home team doesn't have time to expose the new functionality to "userland" code so the other team needs to work with "kernel" code to do so.
    - softwaredoug 3y ago
      No worries :). What I suggest I think is different than away team (which feels a bit like swoop in and crap on host teams codebase). Just saying I prefer it to away team. Fundamentally it’s just a hard problem most large orgs don’t do that well

ramraj07 3y ago

This problem is mitigated if we assume competent engineering teams on both sides - the away team shouldn’t merge code without proper review of the code by the owner, for one, and the away team should go above and beyond in being diligent about code quality, QA and understanding the codebase to the core before changing it. Thus the away team(s) should consist of the best engineers in the org. That’s my read anyway.

NBJack 3y ago
That's definitely not how Amazon works. The most successful engineers there never stay in one place for long. This, plus the perpetual burnout due to things like Away Teams and S-Team goals, means you will instead have a revolving door of talent and fresh hires.

barbariangrunge 3y ago

I was just thinking this. The home team loses some control over their architecture and might gain tech debt this way, especially if different teams have different development philosophies and preferences. Plus, you lose a ton of time implementing features outside your area. Your away team didn’t know that those 5 functions had to happen in order, due to a timing issue nobody could figure out, so your code to change how a panel animates is now breaking unrelated calculations somewhere and causing data loss. You blame the home team for having bad architecture, but then learn a different group of three different away teams set that up and nobody can figure out how to clean it up because of the ripple effect bugs. There be dragons