I think what's impactful about this approach is how it allows a team to share progress and get early feedback from key stakeholders. If you demo to the team that built the software you might get marginal value, but when your leaders are involved, or when key customers are involved, this can be powerful. Demoing a project early is a great way for those with skin in the game to help change course early, or ensure that the deliverables will meet the quality bar they expect before it's too late. It also helps set expectations for how long the average development cycle is, and with tangible progress highly visible, can help ease concerns on timelines and delivery.
This might not make sense at a small company that has few internal stakeholders or that can deliver a feature soup to nuts in a "sprint". In large companies, like Amazon where I work, this is great because the smallest unit of time to deliver any marginally complex new feature or application appears to be somewhere around 3-6 months of effort.
This is a great mechanism for routine check-ins during that time.
It also introduces more entropy as more people may ask for more features or changes on a consistent basis which can impact timelines. Stakeholders seem to ignore the latter.
I'm at Amazon now and my team is often the target of away team work as our system is seen as "critical" to other business unit growth.
it's a farce. Interesting idea in theory, terrible in practice. The away team incentive is "launch as fast as possible at all costs" and that goes about as well as you'd expect.
We constantly deal with shit code and loose rules. Given that many away teams work in different time zones AND Amazon gives them carte blanche to get their work done, the host team can't manage them effectively.
So yeah. On one hand management is like "push back! Make them follow your standards!" while also saying "Don't dedicate time to away teams, you have your own deliverables."
It's a major drain on the home team and can cause a lot of unnecessary stress.
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).
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)
Before Away Teams became a thing there we had people "loaned" to teams to update our code for team projects. I remember during one of the code reviews I did for someone "loaned" to us involved him commenting out validation checks in critical systems that had legal and financial ramifications. When I asked him why he commented it out he said "Oh, my code didn't work with those checks in there so I removed them." I get that the code is complex and he doesn't have the full domain knowledge, but he didn't even ask why they were there and why certain use cases were not allowed for that part of the code.
This model only works if the away teams are the most competent people you have. Generally the “loaning” business is a cowardly way for teams to trade the worst engineers you have (bonus point if that engineer is someone who everyone praises but is secretly shit and only the manager knows that reality).
I don't see how having Away Teams fixes this issue. The Away Team member is still free to write shitty code (or un-write good code, as in this case), and it is still the responsibility of the home team to catch that in code reviews.
The worse case scenario is when the scenario you given: the "pet project," where a team goes nuts on a codebase they aren't maintaining, in which case it's effectively out-sourcing maintenance and tech debt.
Ideally, the home team leadership has a lot of leverage to push back on work by the away team, which means away team work is slow but at least it gets done.
i feel that this assumes the large investors on wall.street are playing the same game as retail investors. Given the size and scale of their accounts, I'd imagine it's an entirely different playbook.
My (limited, retail only) experience tells my gut that most retail investors do it to get rich, and not to learn the markets, learn the risks, and build a business. They are different goals, granted both do seek to make long term gains.
I like to believe that retail investors can make it if they put in the effort and learn to manage risk appropriately. At least I need to tell myself that as I work towards making money in the markets myself.
I am definitely dumb money right now, and I could also be delusional, but saying there is no hope so give up and just do something else completely is just defeatist.
The adage of "It's who you know" applies in all industries, even tech. you are right, it's opinion based. Depending on the values of your team or organization the criteria for success will change.
My principal engineer values "The best possible solution" while I value delivery even if there are some short term tradeoffs. We are often at odds and since he's a level above me, he wins (generally speaking). Because he is a core feedback provider to my promotion I have a harder time getting the feedback I think I should as I'm expected to be his version of a principal engineer, and not mine.
As you move up the ladder it seems convincing people you are successful is more important that actually being successful.
And as much as you can try to push for everything to be measured and to make data-driven decisions, at the end of the day everyone has their insecurities and somebody up the line that you need to convince thinks they're an underperformer.
Something about VB6 felt so pure when I wrote it. it's not fancy and is missing a lot of stuff we take for granted today (pretty sure there is no built in map structure lol) but solving problems in VB6 due to language quirks was always fun.
I can verify that there is no built-in map data structure. Also its "classes" don't support constructor parameters nor inheritance. (Wrestling some debugging issues in a legacy codebase so these frustrations are much closer to hand than I would like.)
I used Angular at my last company. After having used react for many years and then experimenting with svelte, Angular (even the most modern versions) felt like it was always in my way.
Bi-directional data binding and the isolation between style, structure, and logic felt was less productive. Angular has some nice properties, like dependency injection built in, but you can circumvent many of those needs with a functional component tree in react (or limit the surface area across components). The simple fact that you need @Output event emitters to handle callbacks is a good example of how bloated it feels.
It may be that I don't know nearly enough about Angular but even after a year of doing my best to learn the idiomatic Angular ways I wasn't impressed.
As someone who is now a couple years into using Angular after a number of years working with Vue (since 1.0) your observations are accurate. It doesn't really get any better as you become more familiar with the framework.
I have found it better practice to generally emit via a service BehaviorSubject that other components subscribe to rather than passing thru outputs and inputs generally speaking.
I agree with you as I've never seen this side of HR and I've worked at various companies in the US (including Amazon, which was by far my best employer).
The tide in the US seems to be normal people vs business with this idea that all businesses are out to take advantage of employees and I just don't feel that's true in a general sense.
Granted, I'm a highly skilled software engineer making great money and with seemingly limitless opportunities in the current market so saying I have privilege is an understatement.
Well Heroku is overpriced garbage so that's not surprising. They rely on lock in to keep you stuck paying egregious fees for services that are relatively unreliable.
After migrating an entire startup infrastructure from Heroku to AWS I'm even more against Heroku given how easy it is to use something like Elastic Beanstalk to do the same thing without many of the same downsides.
I've been burned by Heroku, though, so I have a strong negative opinion.
Overpriced yes, but garbage? Heroku is definitely stagnating, but they were integral to a whole new genre of PaaS. Heroku got a ton of people's first apps online. Even today their 12 factor app methodology is incredibly useful/powerful.
Now that said I totally relate to having strong negative opinions after being burned. I've got a few orgs like that too. What did they do for you?
Edit: nevermind I should have refreshed. You already answered in a sibling comment
We recently got bit (not quite burned) with the load balancers in the Common Runtime being shared across all apps.
Some piece of malware was associated with one of the IPs of Heroku's load balancers. One of our customers ended up blocking one of our servers associated to that IP because of it. We did some research and we even think we know what app caused it (it's someone's app they host on Heroku), and we don't think it should be flagged as malware, but either way... some other app in Heroku could be truly doing bad things and we would then get our server blocked again.
Heroku's advice was to put up a CDN in front of their load balancers, which has worked for now. But that's extra cost and system complexity just to get around a limitation of Heroku.
We did confirm a Heroku Private Space would eliminate this, since we'd get our own set of IPs for the Private Space's load balancers. But that comes with extra cost, and perhaps even limiting which add-ons we can use in the Private Space.
So although we've generally been happy with Heroku, we are concerned with some technical limitations, like this important (to us) one.
For us it was mainly the fact that every month some part of Heroku is down or degraded. That and the huge price increase when jumping from the standard dynos to the large dynos.
For reference, we migrated to new t4g instances on AWS and received about a 100x performance improvement for a similar (sometimes cheaper) price than Heroku. We are also able to connect to our company VPC and use private resources partitioned elsewhere in AWS (e.g. a redis cluster that costs the same as Heroku with far fewer limitations).
The downside is obviously configuration and learning AWS. Thankfully, we are pretty well versed in AWS here.
Looking at prices is definitely something I’m going to be doing in the short-to-medium term here. We’ve grown our Heroku bill for years, but I’m not entirely sure what all they take care of that RDS or Aurora wouldn’t also handle.
We currently don’t have anyone who is a dedicated sysadmin, so that’s one thing to keep in mind. We’ve been able to rely on shared sysadmin responsibilities here and there, and have Heroku take care of monitoring if our database has somehow “degraded.” But I do wonder if when Heroku identifies that a database needs to be updated, if they’re really just rebranding something AWS does automatically with RDS. I’m just not sure.
Basic things like rolling deployments are still considered "labs" features.
You need double your number of typical connections to support rolling, combine that with the large price jumps and low connection counts on the plans and it becomes very expensive just to have something that should be standard in a modern PaaS platform. This is but one example.
I also find it sad how good Heroku still is when compared to Render or other similar services. Sad because Heroku has built such an incredible experience that others still haven’t caught up to after all these years.
Render is close, but they’re still missing a lot of important details that makes deploying Rails apps as easy as Heroku. Instead they kind of throw the manual at you and expect you to read a tutorial.
Right now I'm on my third job in my career where we've migrated off from Heroku. There have got to be agencies out there that specialize in this, right? If not, it seems like a hell of an opportunity for someone.
