[curun1r]

> It absolutely does if it is only one team in the organization. If the entire organization is using PHP and, let's say, you acqui-hire a team based on NodeJS, unless they are doing something absolutely fundamentally different they should learn PHP and push code in your existing infrastructure.

Substitute PHP with Java, and you've described the situation at my company exactly. The acquiring company had a legacy Java application and a lot of automation invested in making that platform work. The acquired company was a NodeJS shop that was using it long before this article or the comments in this thread would advise (this was pre-npm days). To give you an idea of the numbers, the acquired team was 4 engineers as compared to the 100 engineers of the acquiring company (50/50 split with an off-shore development team). I won't say which side of that divide I was on or go into the full year of culture shock that we went through, but fast forwarding these past 4+ years and now the bulk of the company's main product has been re-written in Node and developers are significantly more productive. Features that used to take months to push out in complex releases using a convoluted process of branching, meetings and tons of arguments are now delivered continually using the Github flow with little-to-no drama and far fewer production bugs/downtime. Our customers have never been happier with us and developers have never been happier to work here. All of this came from the fact that the CMO who advocated for the acquisition supported the small team of 4 in every effort to pervade the small team's technologies and practices across the larger organization. Having been in organizations that performed at a much higher level, he recognized just how much opportunity there was for improvement and recognized that the team of 4 had the vision to create the necessary blueprint for the rest of the organization to follow. It wasn't easy, and most of the developers who were here at the beginning of the shift are no longer part of the company. But it worked...and while a sample size of one is hardly conclusive, I have a hard time agreeing with your point having seen it play out so well in the real world.

[wdewind]

> Features that used to take months to push out in complex releases using a convoluted process of branching, meetings and tons of arguments are now delivered continually using the Github flow with little-to-no drama and far fewer production bugs/downtime.

I have a really hard time believing that Java was the culprit and Node the savior rather than the organizational stuff you mention...

[curun1r]

It was most certainly the organizational stuff that was the main problem. But if, as the poster I replied to suggested, the small team and simply started to submit Java code instead of their Node code, that organizational stuff wouldn't have changed.

Much like a change of location can help break someone's self-destructive habits, the change of platform helped break a lot of the toxic organizational habits that had built up over the years. The shift could have been to many other platforms. And if the platform had been something other than Java, a shift to Java could have improved the situation as well. The important part was that the new mindset and practices around more frequent/frictionless development and delivery.

I do think that it's easier to have that mindset when you use Node rather than Java, but Java has gotten better in this regard over the past few years.

[wdewind]

You're talking about an organization that has an existing infrastructure that is bad. This thread is about an organization that has an existing infrastructure that is good but not 100% optimal for NewProjectX, and whether or not it makes sense to use a a better fitting technology for NewProjectX.

[devonkim]

I've been on both sides of this very important scenario that truly does matter for this industry (the failure rate of acquisitions is hardly as well known as start-up failures when the amount of dollars wasted - oftentimes publicly traded - is probably larger on these sunk costs), and the VAST MAJORITY of acquisitions result in the larger company overriding the smaller with basically just existing customers sticking around out of little choice and almost everyone disappearing (Palm and HP, anyone?). Do you think a company of 4 being acquired would be able to as dramatically affect a company of 200 engineers? How about 2000? What if the engineers aren't even in charge of the platforms they're required to use? (It's literally defined by what your customers want, for example, in a hosted software shipping company)

I am not doubting that your scenario happens, but the possibility of changing a team of 100 (likely pretty jaded) engineers while certainly difficult is not necessarily what people think of when we're thinking acqui-hire. In fact, I'm barely entering my second decade as an engineer and I'm starting to think that surviving an acquisition intact and with career advancement somehow is probably far more lucky than hitting a start-up lottery jackpot in the first place.

There's gotta be a sort of trend of engineers that have gotten acquired so many times that their specialty now is to be able to scale / re-focus technology stacks and integrate and operationalize them better for other companies. Start-up companies typically want to see engineers that have a history of building stuff fast, growing rapidly, and the usual stuff that people get glory for as engineers. Established companies really aren't as picky. There's so many companies getting acquired you'd think that there's a niche for transitioning software over by now at least as contracting gigs.