Had similar experiences with Netsuite and to a lesser extent Jira. So many layers of configuration options and hooks make everything super extensible, but it comes at a a cost and that cost is usually performance.

Yup, the "enterprise" software space is generally incredibly expensive and buggy and a poor user experience, and there is nothing anyone has ever been able to do about it, as firms want custom code just for them, and so the development/maintenance cost can't be leveraged over millions of customers all getting the same software like the B2C space. So given that the market is 3 orders of magnitude smaller, you have a choice of adding 2 orders of magntitude to the cost, and decreasing quality by 1 order of magnitude, or some other combination of this. That leaves you with a few options:

1. Don't allow businesses to customize at all, make them fit to you. That can work with something like ADP, but little else. A lot of the cool B2B startups think they can displace incumbents by just building cool, fast software, and then they are perplexed why they can't gain marketshare when every other customer has some bespoke use case they don't support.

2. Build a general uber-programmable platform that businesses can customize themselves -- now you are in the "slow", "poor user experience" territory but at least it works and is cheaper than option 3

3. Hire consultants to write bespoke products from scratch for each business. That's the old IBM Services model.

So if your baseline is Microsoft Office, then the performance/user experience of your favorite online B2B platform is going to be terrible. But if your baseline is IBM Services, then it's a godsend.

Choose 3 and then watch the consultants build the custom software using a low/no code platform. Now you are still in the slow and poor user experience and no customization options and more expensive and worse support ;-)

I think it’s pretty sad that enterprise software is mostly stuck the way you describe. There are companies willing to invest in fast and user friendly custom software though; the company I work for is pretty successful at doing just that.

All companies in this space start out fast and user friendly, but to gain additional customers in this space they need to add more features. See my first item. Then they either fail or end up an uber-platform. Again, this has nothing to do with your company, it is just the nature of the market, and it's funny when someone gets an idea to start a "lean", "fast" product as if no one else had thought of that before.

Really if you think you can do better than X, whether X is oracle forms or SAP or whatnot, it's important to understand where X went wrong. Hint: it's very rarely because they were "old-fashioned" or didn't realize that customers liked fast software that was easy to use. The founders of X were just as smart/capable as you are, but they faced a market challenge and made some choices with trade offs. If you limit your analysis to "they didn't know software should be fast", then you are not going to end up any better than they are once you reach their scale. I am not trying to say that every incumbent always made the right choices. But an understanding of where they went wrong needs to go beyond "they went wrong because they are old fashioned" or "they went wrong because they didn't realize software shouldn't be filled with bugs". There are real hard problems here that need to be understood before you are in a position to improve on what the incumbents are doing.

I agree, it’s their business priorities which result in engineering that leads to bad software. What I’m saying is you can choose to not buy into one of those uber-programmable enterprise platforms and instead (let someone) build fast and user friendly specific software just for your needs. All of the customization and dynamic crap can go out of the window that way, which will allow engineers to make things fast and user friendly again.

The problem is that the definition of "just for your needs" lasts about a year, max, and then your needs change. Businesses are constantly re-organizing and engaging in process engineering, and this creates rapidly changing needs. Go through this a few times and at some point you will get the bright idea that you need to create some DSL/platform metaframework to allow customers to auto-configure what "just for your needs" means or else you will be buried in a pile of feature requests that your tool doesn't have but the competitor does. And then third parties will come along and you'll want to package their work to create pluggable tools that customers can install. Then you'll spin up app store.

Then throw in all the regulatory and compliance stuff that businesses need to trust storing their data with you. Add EU regulations and you will end up building data centers in different parts of the world. Then you will want to spin up training to use your custom DSP. And localization packs. Then you will need APIs to pull data in and out as customers will fear lock-in and they'll want you to integrate nicely with some other service. Then you have to figure out how those APIs work with your metalanguage. Then other customers will demand the ability to reskin everything with their corporate logos, custom login screens, support for SMS and two factor auth, support for third party identity providers, scripts to enroll/unenroll users, admins will want scripting platforms to manage all the complexity created by adding the other features, Etc.

>What I’m saying is you can choose to not buy into one of those uber-programmable enterprise platforms and instead (let someone) build fast and user friendly specific software just for your needs.

the problem is not everyone can afford a IT dept with software programmers that can build out custom software.

If IT is not their core most companies seek out software that is already out there with somewhat decent reputation.

edit: at one of my previous job, they have a in-house software that was build with older technology that needs to rebuild. they outsourced it to Capgemini. it started when i join the company and by the time that i was out (4 yrs). they still didn't get it covert. they kick out Capgemini around two years in and hand it to another consulting company and the new consulting company junk out Capgemini's code and start from scratch.

i'll like to know more details on how they botched this project, it always make me curious how they botch it up for 4 years and two million wasted.

> the problem is not everyone can afford (a IT dept with) software programmers that can build out custom software.

Agreed, though isn't this often just a problem at a strategic level? C-level doesn't understand digital transformation, so there is no strategy and no budget, or they think they can just buy it with platforms like Salesforce.

Having custom software built is only getting cheaper because our development tools are getting more and more powerful and managed cloud infrastructure is extremely compelling due to removing most of the ops from devops and being cheap at the same time, so costs could hardly be an argument anymore, right?

But yeah, there's always the risk of hiring a firm that has a quality problem, or uses terrible tools to build software in the first place (which is what I was referring to with the joke in my first comment in this thread).

Enterprise software is a minefield, how can we fix that? :)

I have personally seen two 30+ million projects trashed. Not including the wasted man hours spent internal employees to support the consultants. IT projects have an incredible failure rate.

Salesforce was brought in by many sales teams, initially, because the internal systems were too slow to write and the sales teams could just setup salesforce and get going!

You forgot the other part, to make business in the enterprise it matters more to talk to the right people than what the software actually does, and the large majority of such companies see anything IT related as cost center.

honestly if 'fast' is your metric - they'd not be on windows

Someone told me way back in time that in the ERP sales process, your two top answers are:

Q: Can your system do X?

A: Yes (doesn't matter what the question is, or that an entire add-on would have to be built that could never be cost justified).

Q: As a company we do things like this, will your system work?

A: Yes, our product works with your process, no matter what it is.

I have observed this to be true. Customers particularly love the second one, so telling someone that they must change their process to work with your super simple un-customizable product can often be a deal-breaker.

I worked in a startup in the B2B space a while back, and it's amazing how much big customers can push you around and demand features. The salesguys would promise something and then a week later we'd have the feature in a special patch build for them. I heard Cisco did the same thing, and by the time they got big they had hundreds of special branches for different groups of customers. It was a mess.

Then I worked for a couple of big B2B companies (currently work for one) and it's basically the same thing except that two weeks becomes 6 months. But given how small the market is, you are still doing customization to drive deals. I think a big part of the appeal of developing these frameworks is so your own support staff can add the feature in without changing the core code. I'd imagine this would be the case for all the big B2B players. No way do any of these companies survive just selling off the shelf, and I have some admiration for the support guys that parachute into Penn State or the Foo Department of Bar or Nestle and help manage a whole massive deployment or roll out some brand new feature. They are working nights and weekends and I'm sure there's a lot of good war stories there.

Yes, it takes special fortitude to fight off the demands of your precious new mega-customer, be they a Cisco or whoever. Sometimes they'll really screw your product up if you let them. (Though sometimes also they'll give you those jewels of requirements that you really needed).

It's a sliding scale. You have to pander to them to some degree - there's no choice. But it takes grit to refuse to e.g. branch your core code or otherwise compromise your architectural integrity.

The problems are when the sales team does not appreciate the downstream costs of just letting this one patch in. And when you're a struggling startup, sometimes they're right and the social proof of the deal (and the revenue) make it a good choice to compromise your principles this once.

And sometimes you just screw your product up by not listening to what customers need, or by assuming that you know it better than them. For now i refused to do custom branches, instead the product is made more and more configurable. And it's more successful approach so far than trying to maintain a separate version for every customer.

Honestly most businesses think they need a lot of customization because they think they're oh-so-special, but in fact something like 1) would work great for them. I know, I've worked in consulting and built software for companies who would have been better off with an off-the-shelf solution.

Unless there is a product designed for the specific needs of their industry, then the 80% of their needs covered by a generic system still means 20% of their needs are in fact oh-so-special

I once worked on a CMS designed specifically for the print industry by a company that was itself a separate arm of a printing company - and even then we had to have an entire system to write custom estimating engines in Python, because without modelling the exact configuration of machines and processes used in each print shop you couldn't produce a useful estimate for how much jobs would cost.

Love this comment. My company is rebuilding our EHR software right now to make it more customizable among other things. Know any good resources on making the right architectural and product decisions to protect against or prevent this eventual fate?

My general advice is not so much about the software as controlling your corporate appetite for customization. There is just an incredible cost to bespoke customization, while the use cases of it are often things like executives' vanity at getting live dashboards or something else. You can have an in-house team build some forms atop a database, and you can even make that work, but only if you rigidly fight feature creep. If you can't fight the feature creep, might as well go with one of the big solutions so that features are reflected in bottom line costs and have to explicitly be paid for out of your business budget, rather than implemented by making requests of your in-house dev team.

Fix the business processes first or you risk codifying bad business processes in the platform.

This, also if you want a good piece of software to fit your needs the current process must be well documented and reviewed many times.

I am currently working on a large project, which unfortunately needs to communicate with DB2 and interact with AS400 (old ERP system). At this point nobody knows how things work and how the business operates exactly. Managers hold pieces of information but it is not documented at all. I have hit many road blocks because one thing was said, which turned out not to be true after a bit of investigation.

I could develop this software in 3 months, but it is taking 1+ years due to lack of documentation, developers not being on the same page, and nobody understanding the current systems.

Yes. Hire an architect with a proven track record and significant experience and give them the responsibility. Reading a few medium articles or an O’Reily book won’t be a substitute.

no, they just do it horribly - there is no reason to tank perf. it's a system built by consultants, for consultants - aka the people that don't know how to actually do it.

Netsuite is stuck 30 years ago at least. So painful and insanely slow. It’s like having dial up again.

Which ERP isn't?

Maybe none? I think Netsuite is particularly slow though. Luckily I only have to use it for timesheets but even for that it should have its own job number for the time wasted waiting for it to load.

Once an enterprise reaches a certain level of scale that amount of complexity is almost unavoidable. Tools like Salesforce and JIRA are great for providing the needed flexibility within guard rails and a shared vernacular.

I am going through this right now in a project. A lot of configurations break the database model and can't be really modeled by the database so you end up doing a lot in code which is way slower. Seems we need a type of database that can support these super-flexible customizable data models better. Maybe something where the data model and stored procedures written in a language like C#, Java or JS are understood by the database and optimized.

You're not the intended user of Salesforce. The UIs and flows you use are mostly data entry funnels for the true user: management and executives. You didn't pay for the software; they did. "End-user" satisfaction is low on the product feature list.

Every time your client slows down, somewhere an executive was promoted.

"Every time your client slows down, somewhere an executive was promoted."

This is geek poetry.

I’m not sure I understand your point? My understanding is the intended users of Salesforce are most certainly the sales team.

And I say this out of experience with using it as part of a sales team at a car dealership I worked at years ago. Every sales person in the company was expected to log all the customers they interacted with, track phone numbers & other info, set reminders to makes sales calls, make notes of what you talked about in said sales calls, et cetera, et cetera. And management was adamant that we did these things.

And for good reason. Sales is a very data driven industry, so to your point yes, it’s great for upper management to be able to track & aggregate all of the data company wide.

It’s been too long since I used it for me to really remember or comment on the performance of the software. But if it’s as bad as the OP is saying that’s a real problem. If you have a whole sales team using this, and performance issues are constantly slowing them down and wasting time, that’s something that should seriously be addressed.

I guess you’re saying though that they just don’t care if the sales team experience sucks? As long as management gets their data?

> intended users of Salesforce are most certainly the sales team.

Alas, intended users are seldom the ones writing checks. As the old saying goes, decision to go with Oracle happens on golf course, not meeting room.

Nobody got fired for buying IBM!

> Every time your client slows down, somewhere an executive was promoted.

Or wined & dined.

Haha My experience has been bit different with medium size companies. Small companies just dont buy any custom-developed software. Medium-sized have the money to pay for custom development, but not for buying SAP. And the executives are extremely sensitive to the effect of the software on work efficiency - basically this is what they pay for, the software is supposed to make employees more effective so they can avoid hiring more people. If the application gets slow and can't keep up with the business then they need to move more people to handle the slow task and the app developers get grilled. On the other hand, in large companies, management quite often ignores it, they can just hire more people and thus grow their kingdoms.

I made a similar observation while working at a Fortune 500 company that used Salesforce. Decisions about the company's Salesforce implementation were clearly made by people who didn't care too much about data entry UX. The problem was that they did care greatly about data entry -- and data entry, at least in part due to being needlessly cumbersome, tended to fall far short of expectations.

Yeah, I’m definitely not convinced there are configurations of salesforce that aren’t terrible. Other products that are often configured terribly I’ve generally seen an example or two of one that actually was better, but I’ve never seen a salesforce that wasn’t slow as molasses.

URL’s is probably one thing that Salesforce solved well, at least in classic - you’re always routed to the right page by 15 character ID.

Is it heavy JS load on the client side, or slow processing on server side that causes this sluggishness?

The typical JS heap is above 90MB out of the box. Locker service is the main culprit for that, and Locker Service does cause some slowdown. Server-side, they are multitenant and the tenants you are sharing compute with are frequently running massive data operations on a regular basis. Those tenants have no incentive to get things running faster because they don't pay for compute hours. As long as the operations run within Salesforce's governor limits, who cares?

Salesforce's response to the client-side half of the problem is migrating from Aura to Lightning Web Components. LWC is statically analyzable and Aura is not, so they can get some optimizations in that way. On the flip-side, LWC is a piss-poor framework because of how they've stunted it for optimization's sake.

Half of the beauty of Salesforce as a developer is the fact that I can build in a month what would typically take a standard web dev team a year to piece together. That's only true so long as my team works in Aura with all of the scaffolding tools and libraries we've built over the years.

I think it’s probably both. The api and db querying are dog slow too.

Let's hope it's not something laughably simple as adding indexes to their tables! I mean, that's like something I'd forget and I don't even play a DBA on TV

Couldn't agree more! I'd like to add to that the terrible UX. In fact, Salesforce is so terrible that there are dozens of businesses built around just configuring it for you.

But it's enterprise software and real companies use enterprise software, so if we use it we'll also be a real company!

It's slow and the UI is stuck in 1999 unless you pay extra for what they sell as the more modern UI, which takes you from 20+ years behind to only like 5 years outdated.

Lighting is free. The only time you have to pay more is to get custom pieces of your system built in classic rebuilt. In what ways are lightning's UI "5 years outdated?"