Hacker News Reader

Comment by angarg12 | Hacker News Reader

Fellow amazonian here. I have been on both sides of away teams and I agree that it sucks for everyone involved. You explains how it looks as the host teams. It also sucks for the guest team.

* You have to work with an, at best, passive team, at worst, actively hostile team. * You need to work against very tight deadlines and a lot of pressure in a codebase that you know nothing about, and need to ramp up in quickly.

* You spent weeks (months?) developing expertise in a system you will probably never work again.

It is a terrible idea, but to be honest I can't think of another way to deal with the problem that it is trying to solve (mismatch between agendas of different teams).

View on HN

Bubble the issue up the hierarchy until someone with authority over both teams can tell them what is more important?

We resort to away teaming when what you describe doesn't work, usually by telling both teams that both goals are important, and they need to figure out how to deliver.

Since away teaming is an accepted technique, it's usually considered as a way to solve these issues.

I guess we would need to completely give away the concept, and just accept that some thing won't get done unless they are important enough to keep two distant teams aligned (in other words, they are important enough for someone high in the hierarchy).

The open source model? If the away team can't get the home team to fulfill their requirements, they fork home teams code and take full ownership of it for their purposes. If they want to take updates from home team, they do so but have to handle the merging. If they want to, they can try to get home team to take their changes, but that's at home teams full discretion.

How does that work when the thing you want to change is a complex micro-service with a public API? Do you want to spin up your own version of that service and own it forever? Even if you’re okay with that, you’ll not have the clients the older version has

Open-source model works for libraries, or small changes in service code (where the maintenance burden is trivial). But it doesn’t work for complex services with high maintenance burdens

Spin up your own and own it forever would be my thought, yes. This is definitely a high cost to pay - my thought is that the bias should be much more towards modifying the existing service, but leaving the engineers that own the code to be empowered to figure out how to do this. Rather than having management say you have to review this away teams code, deal with it

This would work if the service is stateless (ie owns no data) or the state that it carries can be duplicated without ill effect. A lot of services won't be like that though.

That's a good point. You'd need to figure out what to do about persisted data the service depends on as part of the forking process. In the cases that aren't such that you described, I'd guess most of the time you'd be stuck trying to get your changes merged by the home team - something I think is much more desirable for long term code quality (in theory)

Reply on news.ycombinator.com