That's a very kind way to say: everything in it appears deliberately engineered to ensure continued employment of consultants. :)
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.
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.
> 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...
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.
Lightning was what I was referring to with "custom widgets".
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?
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.
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-...
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.
This isn't to say "never rewrite". I am saying we rewrite way too much now.
peak hn
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.
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.
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.
- 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/...
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.
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.
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.
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...
I've seen this in action, so I know people are willing to pay for it, but it seems really 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.
The tech is proprietary, and not that fun to work with. [0]
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.[1][2][3]
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 something that they should market more heavily in imo. (at least to sw engineers and CTOs) Realistically many companies are not properly equipped to deal with data, let alone sensitive data. Salesforce may have started out as a CRM, but now it is a solution to that problem. CTO's now have someone to point the finger at if shit hits the fan on an Equifax level. This alone is worth big $$$.
[0] - https://insights.stackoverflow.com/survey/2018#most-loved-dr...
[1] - https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...
[2] - https://developer.salesforce.com/blogs/2018/05/summer18-reth...
[3] - https://developer.salesforce.com/page/Multi_Tenant_Architect...
[4] - https://trust.salesforce.com/en/