Hacker News Reader

> The tech is proprietary, and not that fun to work with.

That's a very kind way to say: everything in it appears deliberately engineered to ensure continued employment of consultants. :)

What’s really bizarre is that Salesforce is happy to fly ten of their internal consultants to a meeting, spend all day talking about your business requirements, then end up telling you to hire a 3rd party consultant. I don’t understand what the consultants who work for Salesforce actually do!

They're paid to add value to the customers and be people the customers can trust. This is valuable because when the customer needs something, they ask this person for their 2 cents. When the problem is something a Salesforce tool can solve, the customer is more likely to choose it and either give Salesforce money, or save a bunch of money not having to buy an extra thing (saved money means more budget left over for Salesforce).

Salesforce is built on mutually beneficial relationships. If you go under, they lose your business. If you grow, they make more money selling you more seats.

It's exactly what business should be.

Are you a Salesforce consultant?

Except whenever I ask them for the 2 cents, the answer is “well, there are three different ways you could accomplish that, and we aren’t going to tell you which to use — we recommend you hire an implementation consultant”. Which is a total waste of time.

And I don’t have time or room to get into how awful Salesforce documentation and support are if you try to implement anything yourself. As far as I can tell, the reason they tell you to hire a consultant is that only the consultants have the experience to know the literally unwritten rules.

When I really tried to pin them down on some of these implementation questions, the Salesforce folks actually said “well, we don’t recommend self-implementation”. So when you read all that stuff about it being a development platform, be aware that means for consultants, not you!

So if they’re being paid to develop trust...well, that’s the opposite of what they did.

This happens at Shopify as well.

Business development

I always thought this Demotivator nailed it best

https://i.imgur.com/wlKkBmP.jpg

And in the same spirit: https://dilbert.com/strip/1998-08-24

That's the "economy" part of "application economy": it creates jobs.

> The tech is proprietary, and not that fun to work with.

> As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.

True. But Salesforce allows fairly non-technical people to build fairly robust applications with very limited CS training. If I were interested in getting a technical job but had no experience, I'd consider becoming a Salesforce administrator as a way to get paid to learn to code on the job. [1]

You can build something that is complex and scalable without any programming experience. And what you build will be supported for the next ten years. It's not a terrible proposition for most businesses - especially outside of the Silicon Valley bubble.

[1] https://bluecanvas.io/blog/2017-07-25-getting-paid-95k-to-le...

I've worked with engineers implementing Salesforce at two different companies.

While SF may or may not be the right solution for a problem, I disagree with your assertion that developing for Salesforce will in any way prepare you for a "real" programming job.

You would mostly learn how to configure a lot of UI, maybe write some custom widgets (with Lightning), and write a a little bit of integration code here and there - in an arcane Java-like language.

All you really learn is the Salesforce ecosystem.

You can make very decent money if you can sell yourself. As others have mentioned, Salesforce could be seen as a sophisticated employment scheme for consultants.

But I would advice anyone to steer clear of it as a career path. At least until you have some proper experience in other technologies.

You're still thinking of Salesforce from 5 years ago: https://developer.salesforce.com/blogs/2018/12/introducing-l...

No, that was 1 and 2 years ago respectively.

Lightning was what I was referring to with "custom widgets".

>allows fairly non-technical people to build fairly robust applications with very limited CS training

Ok. BUT... when those limited CS training people want it done right, they hire any one of the huge middlemen do make SalesForce integrations and modules.

ATG is one I know of first hand. Hiring tons of people to make SalesForce suck less. Mostly sales people themselves, then some programmers to do the real work.

This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

Think of the other tech companies over the years that have seemed like behemoths to be utterly knocked out by someone that came in and sucked less. What do you think happened to the industry of Certified IBM Professionals that relied on IBM being market leader in PCs?

> This cottage industry would vanish overnight is SF just sucked less. That's a weak foundation to build anything on.

It's worked for hundreds of thousands of people who make a living from turning raw Access/Excel/Wordpress/Microsoft CRM/Dozens of other products/etc into custom applications that solve the needs of particular business processes.

Every business has its own warts, that no one-size solution is going to solve well, and that will require someone to write a plugin for an off-the-shelf business product.

Outside of the Silicon Valley bubble, most software engineers make a living doing just that.

My first job was writing simple glue scripts that talk to a database for a small biology lab, to help them keep track of their samples and orders. It was ancient. I was so grateful to have the job. Man, I was happy.

This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".

The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.

The result of these rewrites is generally something with fewer features, an unfamiliar interface, and more bugs than what preceded it. Joel Spolsky has a nice article about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Well I mostly agree but you have to consider technical debt

What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?

By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.

1. The people who built the system didn't know how to do things right the first time.

Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.

Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.

2. The problem is actually incredibly complicated, and has no clean solution.

Solution: Don't do anything.

Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.

3. Most of the system is actually fine, there's just a few bad parts.

Solution: Refactor the bad parts.

Non-solution: Rewrite the whole thing, even the parts that are maintainable.

--

I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.

Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.

This isn't to say "never rewrite". I am saying we rewrite way too much now.

> fairly robust applications with very limited CS training

peak hn

Meaning what, exactly?

>> fairly robust applications with very limited CS training

Historically, this hasn't gone well. I'm sure many Software Engineers here can attest personal anecdotes to that.

> peak hn

I believe that are saying that this this is the epitome of what HN has become. ( what they believe to be non-software engineers discussing things. )

While I don't encourage gatekeeping, I think anyone can become a software engineer if they read the right books and spend enough time. I had a similar sentiment about seeing the line:

>> fairly robust applications with very limited CS training

This is an oxymoron. Non-technical people simply cannot build 'fairly robust applications' for reasons they quite simply don't understand. Building robust applications is way more than making it work. You also have to make it maintainable and scalable. Salesforce code I've seen written by people with 'very limited CS training' is neither of these.

I agree with you here, their tech generally lags behind the industry. It's inevitable for such a large company with so many customers relying on backwards compatibility though (the Lightning Experience switch is a counter point to that).

What I have noticed in recent years is that they have been trying to be more open when it comes to their development process, and empowering to open source developers building stuff for their platform. I built a Prettier plugin [0] for their proprietary language Apex and received a lot of support from them. Hopefully that means their ecosystem will get less "enterprisey" in the future.

[0] - https://github.com/dangmai/prettier-plugin-apex

Look no further than the CTO swap that happened a couple of years ago, after the Quip acquisition: https://www.cnbc.com/2018/09/22/bret-taylor-salesforce-ex-go...

Bret Taylor is a modern tech product guy. He led Google Maps, was CTO of Facebook, etc. He's completely altered the DNA of Salesforce and made it a modern tech company.

I've seen this plugin trend on Salesforce Twitter. Can you summarise what does it do that beautify with simple config or Illuminated Cloud 2 formatter cannot do?

Here are a few things that set it apart:

- It is opinionated so teams no longer have to debate about coding styles. It is a refreshing change once you get used to that mindset. IC2 formatter has many configurations that developers can tweak, but that means you as a team need to debate within yourself which one(s) to configure.

- It is a CLI tool. That means you can do things like: run it as a linting tool on every commit to enforce coding styles, run it as a pre-commit hook, auto format files when you save in your IDE, etc. IC2 is closed source, and as far as I know there's no easy way to run it in a headless way.

- It is free.

- It is open source and has been tested on millions of lines of code. If you're using an open source Apex library, chances are it's part of the integration test suite, see [0]

- It is written specifically for Apex/SOQL/SOSL. That means it knows the context of your code and can format based on that. Tools like Uncrustify technically do work on Apex code, but it is being parsed as a generic C-like syntax so a lot of things do not work right (especially when Apex moves farther away from being Java-like).

- It is blessed by Salesforce, and their official IDE (VSCode) will soon adopt Prettier as the formatting tool of choice.

Those are just a few reasons. Prettier has a dedicated page [1] for everything else that also applies to this project.

[0] - https://github.com/dangmai/prettier-plugin-apex/blob/master/...

[1] - https://prettier.io/docs/en/why-prettier.html

> But, I still 100% recommend Salesforce to companies when they ask about it. Why? Data liability. Yes Salesforce is expensive - but you are outsourcing the responsibility of dealing with sensitive data to Salesforce.

This is precisely the reason why my organization, a large Canadian FI on the commercial banking side, decided NOT to go with Salesforce. They couldn’t rationalize giving up the data and went instead with a MS Dynamics implantation. This was 10 years ago.

Salesforce deserve credit for being continuously online as a cloud service since about 1999, and since then regularly rolling out updates and new features to the original codebase without knocking anyone offline. And obviously it has expanded massively since '99 to become the paas behemoth it is today. Think about how brittle code gets after just a few years of incremental updates. Salesforce must have the foundations pretty solidly nailed down to be able to keep expanding the codebase for 20 years without a 'sod it lets just stop and rewrite everything' moment.

> Salesforce is essentially a database as a service with some fancy admin panels and prebuilt web interfaces.

In the sense that my car is just a hunk of metal with four rubber tubes attached.

Seriously, can we please stop these lame attempts to distill extremely complex systems into overly simplistic models using "this is just an X with some fancy Y" type analogies? They don't really contribute anything to the conversation.

It's also better than a lot of the other commercial offerings. At a previous place we had to move from Salesforce to Sage CRM when we were acquired because that's what everyone in the bigger company used ... and it was absolutely awful in comparison.

I don't buy that argument about data liability. I would assume the Salesforce contract indemnifies them from any liability beyond what existing case-law requires. It would be down right negligent by our capitalistic standards for their legal department not to include as much responsibility shirking as they can possibly manage.

They may offer tools related to it but any flaw or issue that exposes your data is still your problem. Remember the trouble Amazon got into for all those data leaks over publicly visible S3 buckets? No? Why would they? Exactly.

It doesn't necessarily have to be about legally enforceable liability. Companies have insurance for that.

Even just from a data management standpoint, they have a business template that is much better than what could be implemented internally.

But after reading "Bullshit Jobs" [0] I think it's more than that - It's more about culpability and plausible deniability of decision makers in companies. Many companies have a CYA (cover your ass) culture. The higher up you go, the worse it gets.

When faced with a challenge that needs to be solved by tech, people in these companies have two choices: 1. Build it out internally, 2. Use Salesforce.

Salesforce is an incredibly safe choice for these type of decision makers. Because if shit hits the fan on an internally led project approved by them, they are associated with that failure. It effects their career trajectory. If something goes wrong with Salesforce - overbudget, data leak, etc. It doesn't matter, someone besides them is first in line to take the blame.

Ever hear the phrase "Nobody ever got fired for choosing IBM"? [1] Salesforce has grown to the point where they are recognized as a standard across industries by non-tech people. I've heard people from small local non-profits all the way up to publicly traded fortune 500 mention Salesforce. Name recognition on this level is quite literally worth $billions in the B2B world.

[0] https://www.goodreads.com/book/show/34466958-bullshit-jobs

[1] https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...

The "cult-like fanbase" is mostly around declarative configuration, and a community of System Administrators that can implement complex rules and page layouts without any code.

So salesforce is worth it because it lets you close your eyes and pretend someone else is living up to your duty of protecting your customers data?

I've seen this in action, so I know people are willing to pay for it, but it seems really shitty.

I use it as part of my job periodically. It is not intrinsically shitty.

When used properly, salesforce provides valuable information and organizes and facilitates coordination around customer-related issues and initiatives far better than anything else that's generally available at the kind of scale it's used for.

The problems start when people who create tickets don't understand how things are supposed to work (because no one gets fucking training), and just end up jamming multiple problems into one ticket.

Aren't they saying that they are ACTUALLY protecting your customers data? Instead of forcing you to do it?