[whstl]

Yep. I also suffered with SharePoint in the late aughts, and eventually consultants were brought in to add some stupid custom feature to out Intranet Wiki that required a month of custom coding.

Plenty of other companies doing that as well. Pretty much every ERP company, for example: from big ones like SAP or IBM, to the ones only popular in their home state.

I remember a consultant telling me “you don’t get it, the point of our app is that you can build ANYTHING the customer withs it”. Well, so is the point of, say, Python.

[tivert]

> I remember a consultant telling me “you don’t get it, the point of our app is that you can build ANYTHING the customer withs it”. Well, so is the point of, say, Python.

Yeah. The idea of generalized, reusable platforms are kind of a siren song for business types.

1. Executive notices the company has 5 apps that sit in a similar place in architectural diagrams. In a meeting, she says: "we have 5 different apps that are creating outputs based on various inputs according to business requirements. She declares, we should have ONE platform to replace those 5 apps. Savings!"

2. Platform team gets stood up. Starts to build the that app according to the new executive strategy.

3. Result: you get a shitty programming language (implemented as "configuration files") with a shitty transformation language. Turns out your platform was actually Java and XSLT, and your previous 5 apps could be understood as "configurations" of that platform.

4. New leadership takes over. The new "platform" gets de-platformized, because it sucks. Now the new platform will be built on the cloud!

[jjkaczor]

Ugh... see - they didn't "get it".

The point of SharePoint was to allow end-users to cobble things together themselves. One of the original design philosophies was "Excel on the web", hence the reliance on it's Lists as a core data structure (as inappropriate as it would of course become, when users started treating them like giant RDMS stores). My anecdata is from talking to some of the original design team members, from when Microsoft acquired it from VTI.

It was originally not intended for developers, it was for power-users. The fact that it was built on .NET technologies made it extensible though, and boom - quickly enough there was a huge market.

[whstl]

Well, here's the thing... you're not wrong. You're actually 100%... scratch that, 120% correct!

Software shouldn't really be a constant struggle. It shouldn't be about constantly forcing square objects into tiny round roles.

However, when you're an experienced developer that's easy to see. Sometimes even when you're inexperienced it's also easy... But when you're upper management, and a developer says "we shouldn't do that in Sharepoint" while Microsoft is telling them "this is 100% possible in Sharepoint" and the Microsoft approved consultancy says "this is extremely easy in Sharepoint", the developer ends up looking bad! :(

[arethuza]

One approach to dealing with that is to then suggest that if things are so easy then surely the consultancy would be willing to do the project on a fixed price basis?

[whstl]

Yeah, that would do the trick. But then again, in companies with thousands of employees this kinda things tends to get lost in translation between the multiple management layers, or when some over eager product manager decides to make their life goal adding some weird customization to SharePoint at any cost possible :/

[krylon]

It does allow people to build useful things, I'll give them that. But our company didn't have any power users, so us admins got handed the task of doing that as well. (manic laughter)

[jjkaczor]

Heh... I had a client, as recently as 2020 who barely had "users" - who didn't know how to perform basic computer operations (Cut/Copy/Paste, navigate menus, etc).

Hell - yesterday, I was working with a DBA over remote screen-sharing who had no idea how to enable the display of line-numbers in his preferred SQL text editor... (Or even that you have to press "OK" to save your changes in a modal dialog box...)

[krylon]

I don't mind if you build a lot of stuff on top of it. But if the vendor more or less withholds useful documentation from their customers on purpose to make them buy their training and certifications or hire their consultants, that's a dark pattern, isn't it?

[whstl]

Well, yes, definitely.

And that’s the business model of a lot of ERPs, especially mid-sized ones. Some of them even have private configuration software, and I even remember one having a private “special compiler” that was just applying something equivalent to a ROT13 to the code and zipping to discourage customization by customers.

But the crazy part is that you don’t even need to resort to this. Unless you’re SAP or something like that, there’s no chance in hell that a developer will want to hitch their career to your shitty ERP, so consulting it is.

[arethuza]

Any "platform" based approach is going to have that weakness - if you are in the domain where an ERP is a good fit then you'd be crazy not to use one, if you're problem isn't actually a good fit then you can end up in a whole world of pain and you'd be better off with a general purpose dev environment.

Unfortunately deciding this in advance can be tricky.

[whstl]

Yep, good points.

Indeed, during decision-making time, the people signing the checks always think that everything will fit nicely.

With customizable ERPs, what I have witnessed all my career were companies refusing to change their (universally hated, bureaucratic, insecure and inefficient) internal processes and having to pay more for customization.

The problem in the end is that there is rarely any shift, unless you have major cultural shift and oversight, coming from someone with the intention to save money and custom development time.

Inertia always wins.