* They seemingly can't recover from this GitHub debacle (it's been a month without GitHub Sync).

* They had a massive security breach where core-db was breached. Hashed user passwords and encrypted env vars were leaked. (And a hell of a lot more I bet—but they haven't admitted this)

* They're operating with probably 1/3 the staff they were at peak due to attrition with no backfill and a layoff.

* They've been under a feature freeze for going on 5 years. Check Heroku Changelog to verify this yourself: https://devcenter.heroku.com/changelog

Yes: Heroku failed.

EDIT: just because Heroku has failed in 2022 doesn't mean it wasn't also successful. It's not too different than Flash in that respect.

That's different. Heroku itself was a massive success. The Salesforce management completely screwed up the department after the acquisition.

That's on Salesforce not Heroku. Heroku left the building already.

Agreed. Heroku was an incredible success but using it in 2022 would be downright negligence.

(Although I would argue that Salesforce was also responsible for creating most of what we love about Heroku. That acquisition happened far earlier than people realize. They're also almost entirely responsible for its downfall.)

EDIT: Craig is right below (and he pretty much always is). When I said "created" I really meant in terms of giving them enough financial resources to keep building. SFDC exerted no influence in terms of product decisions early on (so far as I know). Re-reading my post I see that wasn't clear.

That Salesforce created it was wrong. That Heroku was already that way, yes also re-painting history. Cedar and buildpacks were conceived before the acquisition but launched after. The teams were allowed to continue executing on roadmaps for multiple years after the acquisition, but Salesforce could be viewed more like a series b, c, d round than in a way influencing the roadmap and making it happen.

GitHub is an amazing parallel, folks feel that Microsoft turned around GitHub, but actions and much of the GitHub turn around happened long before the acquisition. Those sort of things take years, you should mostly try to judge a top down influence 4-6 years after they were there.

> [Github A]ctions and much of the GitHub turn around happened long before the acquisition

Interesting - someone at either MS or Github told me that the Azure DevOps team moved over to GitHub to create Actions. But maybe I misheard or both versions are true.

Here's what I think the two potential scenarios you map out are:

- That Jason Warner, Max Schoening, and a brains trust of Heroku Product & Design leadership jumped ship to GitHub. After they got there they continue their run of product success and innovation and launch the next platform innovation for GitHub. Which also just happens to be yet another way to run code as a service.

- The ADO team join GitHub, and then pivot into a whole new and foreign area.

People can make their own judgements on which of these is the most likely option.

Yeah, not sure how much I can say, but this is definitely a repainting of reality. Actions at least the vision of what it would/could be was before acquisition.

As an early adopter of actions I remember that it was wildly different in its first version (beta perhaps?) than it is today. I have no source to back this up because it was too long ago, but I feel like I remember hearing at the time that the reason it changed so much was _in part_ because of the ADO presence. So I think you're right that the vision was there before hand, but what we have today is very much because of the influence of ADO (in particular, the mandate to run actions _on_ Azure, IIRC).

Agree. I like simpler. Most of my coworkers do not prefer simpler. They want to use tons of AWS services.

Resume-Based Development.

My employees are the same. They want to tick all new tech boxes with our product, and they’re right, because they exit with 35% higher pay elsewhere (and I clearly don’t underpay them - this market seems to have no upward limit, and the only thing I’d like from them is taking ownership and responsibility, and it’s not happening).

Are you actually offering them ownership, i.e. large enough equity to have any say in corporate matters? Not just financial instruments that can lead to ownership after a years-long vesting schedule+exercising?

Will they perform better if I give them a million dollars for free?

So your main complaint is: "People without ownership act without ownership"?

The basic principle of ownership is:

- You get $0 on day one,

- After the job is done and it hits the market, you may get a million dollars.

What employees want:

- Be paid full market rate from day one even if it doesn’t work,

- AND ALSO getting dividends if it works,

It looks like you are just advocating to give them more more more. But let’s entertain the idea of implementing your advice seriously:

- I’d have to hire entrepreneurs who understand how market moves and what the risks are,

- I’d have to sell them stock on a given FMV that we determine together (Fair Market Value, =valuation per share), so FMV=0$ when the company starts, but it’s much higher when they join 5 years later when the product has already hit big and the good ideas are there. Estimating valuation is extremely hard and they would probably feel on the hook. If I value the current company at €6m, so let’s say €2m as a rebate, they’d have to get €600k out of pocket to buy shares; If they buy only €100k because they don’t have the lumpsum, they’d get 1/36th of dividends. We’ve made 1m this year, that guy would get 20k. You see, it’s hard to estimate a company clearly. If they don’t get large dividends, they’d complain I had cheated them with a too high valuation. And programmers in France don’t have economy education in their curriculum, so they’d think I cheated them, rather than them not producing the proper output (people with no economic education tend to get angry at people around them when they take the wrong decision),

- They’d leave the boat to work somewhere else as soon as the market shrinks, and they’d still get 1/6th of our dividends without working for us, which has a disproportional impact on those who stay,

When you think about how to do your advice in practice, I don’t think it solves what you think it solves.

If all you offer is a pay cheque, don’t complain people only work for the pay cheque.

I’m not telling you how to run your company, or offering any solutions. I’m just trying to offer some perspective.

You don’t transform people by giving them the power of deciding.

> Resume-Based Development.

Love this! Had not heard it before.

I've also noticed a trend of coworkers wanting to add a lot more servers than we need for capacity and redundancy. As in they don't even look at New Relic. Reality is most of the bottleneck is database or the code needs to be refactored. Code written for a few thousand records is often not going to work when there are millions of records.

Another argument is moving parts of the monolith to a microservice because that would take load off the server.

> microservice

At least it has become a running gag in our company that anyone suggesting microservices is joking. It’s a good first-step towards limiting Resume-Driven Development.

For the scale of our cloud product (1000€/month for now), we could manage everything in memory.

> Heroku inspired a lot including direct competitors (like Cloud Foundry). A lot of money has been made and people jobs make easier.

Ah Cloud Foundry. Something I drink to forget.

CF was the tool Salesforce should've bought or written. Heroku not so much.

Was it so bad? My experience with it was resoundingly positive, and saw lots of productivity gains with a great developer experience for teams that could build apps with strong guard rails in place.

Now everyone and the kitchen sink „needs“ their own kubernetes cluster and operations teams struggle to build complex landing zones for the underlying cloud infrastructure so teams don’t shoot their own foot off all too easily…

For context: I was at a company that was trying to roll out OpenStack internally (don't do this). Lots of stuff got thrown at the wall in an attempt to find a unified provisioner, nearly all of it terrible. Thankfully my role was that of a consumer.

My recollections were that BOSH and CF exposed a ton more complexity than I wanted, and I don't remember there being a great story for deploying Rails apps. But all of these abstraction layers are just like cross-platform GUI toolkits – you're never going to approach the native look and feel or integration. And I don't like the terminology(!) it's all relatively unintuitive to me (e.g. stem cells, deployments, releases).

For contrast the Hashicorp stack for our AWS environments (tf+packer+vault) generally felt much more pleasant to deal with, and that's where the comparison to GUI toolkits falls apart I suppose.

But… look at all the integrations and enterprisey features that CF+BOSH offer. That's way more of the sort of thing that I'd expect to fit in at Salesforce.

Agreed on the complexities of CloudFoundary, there’s a ton of work going on behind the scenes to make it work.

That said I think the Hashistack doesn’t address the PaaS component. There’s no cf push with HashiCorp tools.

It’s early days but maybe WayPoint will make that happen.