SharePoint development

[[)roi(]]

...However, it was pretty much unmaintainable..

That's pretty much the outcome for any SP system where you have idiots thinking it can be the cornerstone solution within a company; the same abortion used to be common place with Lotus Notes.

 

[scudsucker]

company in PTA/Centurion side per chance that you worked for?

I worked in the CT office (in Durbanville) but Head Office was indeed in Centurion. One of the big investment/financial houses...

 

[[)roi(]]

How about we turn this thread on it's arse and rather discuss what you would consider to be better alternatives to SP.

I'll cover a few examples of some of the bigger issues with SP type solutions (one's that can't be overcome by simply employing a skilled developer).

All your eggs in a single basket:

• Beholden to a single software provider. The chances of Microsoft buckling are remote but what about the chances that SP is deprecated, or even worse that it stagnates: e.g. stuck in a rut with old structural design problems; I'd argue it's already there.
• Narrow development skillset. Tackling new requirements is going to be challenging because you're limited to resources skilled in the SP space, and your ability to split the work load amongst multiple teams is unlikely not only because of market resource limitations, but also technically because of the SP architecture.
• Continuity challenges - some continuity guys love a single basket, restore that and everything is up and running, problem is that when it doesn't the impact is huge, and let's not ignore the extended recovery time; skills also come in to play re your skillset for recovery is narrowed to techies skilled in SP and/or Microsoft tech.
• The pie in the sky notion that write once run everywhere is a viable solution for everything. Neither Java or Web apps were able to successfully bridge this area.
• etc...

I haven't even touched on the software engineering technicalities, but I think the web is littered with these examples, so I won't spare you the Google search.

In short I believe the best architecture
is one which avoids the single point of failure, adopting the best technologies utilizing a multitude of resources and development skillsets; e.g. If you make your data available with web services you won't limit the clients that can be built / plugged in to take advantage of this.

Plus let's not forget there are so many ready made solutions, and many are open source.

 

[kripstoe]

In some instances, SharePoint must not be used. Saying that, there are many customers where SharePoint has been running successfully for years.

How about we turn this thread on it's arse and rather discuss what you would consider to be better alternatives to SP.

I'll cover a few examples of some of the bigger issues with SP type solutions (one's that can't be overcome by simply employing a skilled developer).

All your eggs in a single basket:

[*]Beholden to a single software provider. The chances of Microsoft buckling are remote but what about the chances that SP is deprecated, or even worse that it stagnates: e.g. stuck in a rut with old structural design problems; I'd argue it's already there.

And that's not a possibility with any other platform out there? The problems that you're referring to, might actually be there by design for a reason.

[*]Narrow development skillset. Tackling new requirements is going to be challenging because you're limited to resources skilled in the SP space, and your ability to split the work load amongst multiple teams is unlikely not only because of market resource limitations, but also technically because of the SP architecture.

Nope. Resources... err... people should be skilled in various aspects, including and not limited to SP. The SP architecture should not be a limitation. If it is, it is being approached/implemented incorrectly. Or the people doing it, do not have the right skillset.

[*]Continuity challenges - some continuity guys love a single basket, restore that and everything is up and running, problem is that when it doesn't the impact is huge, and let's not ignore the extended recovery time; skills also come in to play re your skillset for recovery is narrowed to techies skilled in SP and/or Microsoft tech.

Possibly, but catastrophic failures such is this is possible elsewhere also. As far as I know, there is no stats that show SP to have a high failure rate in this regard.

[*]The pie in the sky notion that write once run everywhere is a viable solution for everything. Neither Java or Web apps were able to successfully bridge this area.

Not sure I follow this in the context of SP?

[*]etc...
I haven't even touched on the software engineering technicalities, but I think the web is littered with these examples, so I won't spare you the Google search.

You can say that about Googling that for [INSERT PLATFORM HERE] also. It does not prove one platform is better or worse that another. Again, in my opinion this comes down to the knowledge and skill shown by the people implementing. I've seen horrible implementations of various kinds of things. Mostly, it's the people.

In short I believe the best architecture
is one which avoids the single point of failure, adopting the best technologies utilizing a multitude of resources and development skillsets; e.g. If you make your data available with web services you won't limit the clients that can be built / plugged in to take advantage of this.

Plus let's not forget there are so many ready made solutions, and many are open source.

Cool, I mostly agree here. Still does not mean you should never use SP.

 

[[)roi(]]

In some instances, SharePoint must not be used. Saying that, there are many customers where SharePoint has been running successfully for years.

Show me a successful SP installation and I'll show you an engineering group probably stifled by an overbearing management.

And that's not a possibility with any other platform out there? The problems that you're referring to, might actually be there by design for a reason.

As soon you have to rapidly scale up the solution and/or spread it around the map and/or fine tune latency / performance, you'll throw it and many others like it out.

Nope. Resources... err... people should be skilled in various aspects, including and not limited to SP. The SP architecture should not be a limitation. If it is, it is being approached/implemented incorrectly. Or the people doing it, do not have the right skillset.

In a small house, building small solutions with extended timelines; but when you're pushing multiple device types in a compact timeline, multi skilled developers ain't gonna cut it. That's when not being locked into a skillset is valuable i.e. being able to hire the Android guys for the Android build, iOS guys for iOS build, Windows for the Windows build, etc....

Possibly, but catastrophic failures such is this is possible elsewhere also. As far as I know, there is no stats that show SP to have a high failure rate in this regard.

That's a sign of:

• overbearing management,
• lack of funds,
• poor engineering
• rubbish solution
• etc..

I could go on but you should get the general idea. Naturally an assessment should underpin most of these decisions i.e. build infrastructure around the impact that the business can afford. Problem with solutions like SP, Lotus Domino and others -- is that the infrastructure vs business continuity vs risk IMO is rarely revisited after the initial investment; that's the benefit of isolating tech, the business case is certainly easier i.e. cost separation is a lot easier.

Not sure I follow this in the context of SP?

Building / fine tuning apps for each device versus a generic solution that doesn't work so well on any.

You can say that about Googling that for [INSERT PLATFORM HERE] also. It does not prove one platform is better or worse that another. Again, in my opinion this comes down to the knowledge and skill shown by the people implementing. I've seen horrible implementations of various kinds of things. Mostly, it's the people.

Sure but this in context of SP; far too many examples of where this tech has been badly developed / deployed. See this thread for an example.

Cool, I mostly agree here. Still does not mean you should never use SP.

Great +1

 

[kripstoe]

Show me a successful SP installation and I'll show you an engineering group probably stifled by an overbearing management.

I can. And the engineering group isn't stifled by management. The solution fits the usage scenario.

As soon you have to rapidly scale up the solution and/or spread it around the map and/or fine tune latency / performance, you'll throw it and many others like it out.

You can scale up an SP solution. On premises not so fast, but in the cloud fairly quickly. If you're looking at something that needs to scale very quickly, then SP wasn't the right option to start with.

In a small house, building small solutions with extended timelines; but when you're pushing multiple device types in a compact timeline, multi skilled developers ain't gonna cut it. That's when not being locked into a skillset is valuable i.e. being able to hire the Android guys for the Android build, iOS guys for iOS build, Windows for the Windows build, etc....

How do you change your solution to fit your opinion that SP would not cut it? Obviously it depends on the usage scenario.

That's a sign of:

• overbearing management,
• lack of funds,
• poor engineering
• rubbish solution
• etc..

I could go on but you should get the general idea. Naturally an assessment should underpin most of these decisions i.e. build infrastructure around the impact that the business can afford. Problem with solutions like SP, Lotus Domino and others -- is that the infrastructure vs business continuity vs risk IMO is rarely revisited after the initial investment; that's the benefit of isolating tech, the business case is certainly easier i.e. cost separation is a lot easier.

Most investments into these type of solutions also allow for fairly robust infrastructure, backup/restore solutions, high-availability, failover, etc. If the implementation does not take this into account, then SP might not be a fit.

Building / fine tuning apps for each device versus a generic solution that doesn't work so well on any.

How do you change your solution to fit your opinion that SP would not cut it? Obviously it depends on the usage scenario.

Sure but this in context of SP; far too many examples of where this tech has been badly developed / deployed.

There are examples of developers implementing badly developed C, C++, C#, JavaScript, SharePoint, Lotus Notes, Dynamics CRM... [insert tech/platform here]. Does that mean C, C++, C#, JavaScript is all bad? No.

I completely agree that SP is really crappy in some instances - I would also advise against it sometimes. Hell, there are some SP things that are very frustrating. Saying that, there's A LOT to be learnt from SP also. It has good parts, bad parts, parts that have been improved, parts that work extremely well. Scenarios where I'd definitely recommend it.

It really depends on the scenario, and the skill of the people implementing it. I'm open to implementing any solution that fits the requirement, where people are competent implementing it.

I would not just rubbish any technology because I don't like it, or can find many posts in Google rubbishing it.

 

[[)roi(]]

You can scale up an SP solution. On premises not so fast, but in the cloud fairly quickly. If you're looking at something that needs to scale very quickly, then SP wasn't the right option to start with.

I work with large corporates, haven't found any who trusts the cloud.

There are examples of developers implementing badly developed C, C++, C#, JavaScript, SharePoint, Lotus Notes, Dynamics CRM... [insert tech/platform here]. Does that mean C, C++, C#, JavaScript is all bad? No.

I completely agree that SP is really crappy in some instances - I would also advise against it sometimes. Hell, there are some SP things that are very frustrating. Saying that, there's A LOT to be learnt from SP also. It has good parts, bad parts, parts that have been improved, parts that work extremely well. Scenarios where I'd definitely recommend it.

It really depends on the scenario, and the skill of the people implementing it. I'm open to implementing any solution that fits the requirement, where people are competent implementing it.

I would not just rubbish any technology because I don't like it, or can find many posts in Google rubbishing it.

Awful developers and badly written code aside. SP as I said took the concept of Lotus Notes and made it worse, however the SP cheerleaders and Lotus Notes ones are no different, it's a uphill fight until you show them something easier / better.

On the crappy part we agree; where we don't is that I've never found a scenario where SP was the better choice. Lessons to be learnt, sure: the lesson IMO is the same as Lotus Notes; there are far too many great alternatives to buy into the SP pray.

 

[kripstoe]

I work with large corporates, haven't found any who trusts the cloud.

Also work with large corporates (local and abroad), and many do trust the cloud. At present, it's mainly a matter of cost.

Awful developers and badly written code aside. SP as I said took the concept of Lotus Notes and made it worse, however the SP cheerleaders and Lotus Notes ones are no different, it's a uphill fight until you show them something easier / better.

On the crappy part we agree; where we don't is that I've never found a scenario where SP was the better choice. Lessons to be learnt, sure: the lesson IMO is the same as Lotus Notes; there are far too many great alternatives to buy into the SP pray.

I'll accept that we have had different experiences with the product.

 

[[)roi(]]

Also work with large corporates (local and abroad), and many do trust the cloud. At present, it's mainly a matter of cost.

It's never a matter of only cost. It's always a matter of corporate security.

None of the cloud providers (Microsoft, Amazon, etc.) provide concrete guarantees, for example: corporate espionage.
Hence the "cloud" oriented solutions I've built have been private, managed by a 3rd party but never with the standard Cloud contract.

I'll accept that we have had different experiences with the product.

I've worked with Lotus Notes since 1991, so its more a case of I've never seem any scenario where SP was better, cheaper and easier to maintain versus alternatives

 

[kripstoe]

It's never a matter of only cost. It's always a matter of corporate security.

None of the cloud providers (Microsoft, Amazon, etc.) provide concrete guarantees, for example: corporate espionage.
Hence the "cloud" oriented solutions I've built have been private, managed by a 3rd party but never with the standard Cloud contract.

Yes. I didn't say corporates do not evaluate security. I said, at present the main issue with cloud is cost. And not just the cloud costs.

I've worked with Lotus Notes since 1991, so its more a case of I've never seem any scenario where SP was better, cheaper and easier to maintain versus alternatives

Cool.

 

[[)roi(]]

Yes. I didn't say corporates do not evaluate security. I said, at present the main issue with cloud is cost. And not just the cloud costs.

Cool.

No worries mate (experiences differ)

I've seen many shops with extensive builds on SP and Lotus Domino; however never a shop that was doing something (so special or unique) that it couldn't be done (cheaper, etc...) on an alternative. I have however seen ones who thought using SP for the marketing guys to capture / update customer data (via mobile phones) would be a good idea; not surprising they've thrown SP out.

 

[Pho3nix]

No worries mate (experiences differ)

I've seen many shops with extensive builds on SP and Lotus Domino; however never a shop that was doing something (so special or unique) that it couldn't be done (cheaper, etc...) on an alternative. I have however seen ones who thought using SP for the marketing guys to capture / update customer data (via mobile phones) would be a good idea; not surprising they've thrown SP out.

And just like that SharePoint brings people together

 

[Arthur]

Clunky? Clumsy? Difficult? Hard to work with? Lots of engineering and performance challenges? Sanity-destroyer? Lots of business demand?

Sounds like the ideal way for a skilled and savvy developer to make some money.

 

[[)roi(]]

Clunky? Clumsy? Difficult? Hard to work with? Lots of engineering and performance challenges? Sanity-destroyer? Lots of business demand?

Sounds like the ideal way for a skilled and savvy developer to make some money.

There's always a business case for doing something everyone else considers awful, however there's a fine line between doing the crap work and delivering it.

 

[kripstoe]

And just like that SharePoint brings people together

See, there's always an upside.

 

[kripstoe]

There's always a business case for doing something everyone else considers awful, however there's a fine line between doing the crap work and delivering it.

On the topic, what other technologies do you consider awful? Not directly similar to SP, but in general.

 

[[)roi(]]

On the topic, what other technologies do you consider awful? Not directly similar to SP, but in general.

That's a very broad topic, its not that I hate a lot of tech, rather where and how a particular tech is employed.

There are however a few off the top of my head that I have a distinct dislike of, for example:

• Javascript - for reasons I covered in a quite a number of posts. Basically it's an awful language.
• OOP (Object Oriented Programming) - It promotes new age spaghetti code, especially when somebody goes overboard with refactoring. As I've posted before I'm a firm believer in FP (Functional Programming), XP (Extreme Programming), TDD (Test Driven Development) and the vanilla (Imperative Programing)
• JIT (Just In Time) compilation coupled with GC (Garbage Collection) e.g. Java, C#, etc..., as opposed to compiled languages, manual memory management and / or ARC (Automatic Reference Counting) e.g. C, C++, Swift..

Naturally everyone has their pet peeves and its going to vary depending on your environment and current exposure, etc...