[bloppe]

I work at a FAANG company on a project from a recent acquisition. The "narrative" of the startup was much like this article describes; a few rock stars knew everything and delivered sweet features everybody loved. Well, now those rock stars are gone, and we're left to pick up the large tech debt tab left over from their free-wheeling days of fast features and relatively poor documentation, code health, and testing.

I get why this happened. A startup has to deliver features now if they want to get acquired. It's a completely different mentality from the one we have now: no worries about funding, and we want to do things right in a way that will be robust long-term. Realistically, this is how it was always going to go down.

But I can't say that this is ideal. You don't want a couple rock stars carrying your project if you also want that project to be around in 10 years and can't guarantee that all your rock stars will be dedicated for life. You need somebody else to be able to pick up the torch. You want "commodification" (although I don't think it's a very accurate term; it's actually hard to get this right, not easy, but the alternative is much worse over time).

[YZF]

I worked at an S&P 500 company on a project from an acquisition. It was extremely well engineered. Reliable. Attention to details that you sometimes don't see in larger companies. A lot of seasoned amazing engineers worked at that startup.

I think there are plenty of examples of amazing software coming out of small teams or even single developers and plenty of examples of large corporations producing garbage with huge teams.

> we want to do things right in a way that will be robust long-term.

If you don't have the right people that know what "right" is and have seen projects through the long term then this is often used as an excuse to over-engineer and do work nobody cares about. At least that's my experience.

[iot_devs]

I work in FAANG as well.

Never seen a place with worst technical debt, complexity and just difficult to work in.

I am convinced that commodification is what is actually causing all the issues we are seeing.

A bunch of mediocre developers getting in the way and creating complexity without any creativity, out of the box thinking or even holistic view of the system.

But management wants more people so that everybody can leave and not holding the company hostage.

Guess what? It is only worse. Very few people can actually make progress and those people are constrained by the whole team around them.

[vikramkr]

Was the acquisition a win for the company that sold it or was it more of an aquihire deal? In the success case I think you could argue that was actually the ideal type approach for that company - focus on getting to the point where you or an aquirer can safely adopt that sort of long term mentality and clean up the codebase (or not, if it's good enough). Most projects aren't aiming to be built to last 10 years and slowing down enough to get that right might mean its a moot point if they never shipped. Having to deal with a garbage codebase for a successful product is a good problem to have because it means you have a successful product

[edandersen]

There are easy ways to make the rockstars "dedicated for life". It's just seen as expensive.