It's the scaling nature of enterprise software. If you have a mature B2C app, you have millions of users. What each user wants isn't so important, so it's more of a take it or leave it experience. If you have an enterprise app, one big company can and does push you around to get their features in. And as you grow, you get a few hundred big companies that push you around. The result is this huge mess of features, and now you have to maintain this mess.

I remember Cisco before iOS used to have hundreds of branches for their router, one branch for each major customer that was demanding specific features. It was unmanageable, but that's what you needed to do to win those "enterprise customers".

It also turns out customers aren't very good at articulating their needs and putting them into a cohesive vision of the product. But they sure have specific demands to get stuff in. I'm not blaming the customer, this is just how this world works -- All of the "enterprise software" apps are extremely complex with hidden knobs and weird behavior that was pushed in by a customer twenty years ago all over the place.

> I remember Cisco before iOS used to have hundreds of branches for their router, one branch for each major customer that was demanding specific features. It was unmanageable

Ouch. I heard of a company in my home town (small B2B service provider) doing something similar - they paid well but I didn't think it was worth it.

I think it’s like advertising - 50% of my code is wildly over complicated - I just don’t know which 50%

But the GP is essentially correct - there is a 2% of salesforce that could be built run and keep 80% of salesforce users happy. Except that you could not charge enough to be able to advertise on F1 cars and take SVPs out to dinner.

So you could not actually make 80% of them happy - they would ever buy it.

> I just don’t know which 50%

Yes, you largely do - they’re the commits that get rushed to, and through.

This take that showstopping technical debt is unavoidable is very new, and will age like milk.

> showstopping technical debt is unavoidable is very new

No it's not. The push and pull between shipping and paying down technical debt is as old as there's been software to sell. Sales has been selling features that don't exist quite yet ever since they've been talking to customers, and engineering has been pushing back on implementing them yesterday since there's been features to implement. Showstopping technical debt is merely a side effect of who wins that argument in a given org.

Yes.

My point is the technical debt is stopping the show way more often.

Not “this never existed before selling”,

but “we never had the team in place who could do this right in the first place”.

You can quibble about who is responsible, but the fact remains.