SharePoint How Sad Are We

<< Too Much of Coffee: Definitely Not Good For You | Home | Slow DSL Upload Speeds Problem Over My SBC AT&T Connection >>

SharePoint How Sad Are We

Technorati Tags: Rants

SharePoint SharePoint how sad are we

Your marketing promise me everything under the sun & as far as my eyes can see

A hidden cost, a nasty toss, a huge 5 year loss

Go hire a whole team, 3^rd party pugs-ins, SharePoint consultants with nothing BUT cost

SharePoint SharePoint, I hate you so

You’re a clown with a funky smile, but do you fool me? hell no

You are a big smelly beast running sweaty into the night

Because your API is so bad, developers constantly put up a fight

SharePoint SharePoint what horrible code

Code that must dance around this API that’s just too messy and cold

I love to become a master of all trades

How to debug SharePoint’s bad errors, pile of code, and adding never-ending band-aids

SharePoint SharePoint, you’re a big ass joke

You’re page model not even in .NET 3.5 yet, sad, so you leave me in smoke

When the next upgrade comes, developers better run for the hills

And hope you never customized it in the past, else late nights, & footin the bills

I leave you with this video, and last comments at the end.

I would much rather know I can code and extend my application with quality design patterns and take just a little more time with it without boundary for the business, rather than become a master of disaster at getting around a lousy SharePoint bloated API and funky way to code around it and hack the thing or deal with its lousy limitations. Instead of developing, you end up throwing a ton of plugins or worse, deciding to use a system like K2 or InfoPath (a huge messy beasts) just to do workflow instead of using straight code & WWF in the first place.

Ok out of box, but not ok to extend my friend. Because in the end, cost beats custom on this one (if you are thinking about an end-all solution other than just document management that is). leave Sharepoint to the out-of-box document management. Leave the rest of the business to REAL code. Don’t try to squeeze something that it is not.

Just a sample of a few of probably hundreds of related links on the web:

Sharepoint is not a good development platform (by Jeffery Palmero)

SharePoint 2007: Pointedly unskinnable

Is creating a view on SharePoint tables bad style?

I'm a developer, and I hate SharePoint

Sharepoint 2007 - insanely bad HTML

SharePoint Development is an Adventure!

I hate SharePoint (and so do you) – Part 1

I hate SharePoint (and so do you) – Part 2

SharePoint Sucks.

Why SharePoint Portal Server is Terrible

SharePoint sucks at document management - or does it? A metal perspective

"Developing for sharepoint is nothing but a nightmare. The system is overly complex, unintuitive and just plain bizarre"

Bad naming - Sharepoint Features

The Good, The Bad and The Ugly of Sharepoint 2007 Development

What’s my point? Yes, this is a rant, because I can. It’s a horrible development platform, inflexible, and a huge cost to organizations that ever want to “extend” this pile all due to Microsoft’s over marketing of a glamorous UI that is fine if you DON’T try to customize it or extend it beyond it’s out-of-box functions. Sure, you can extend…and break your organization’s back and piss off your developers who hate working in it…at least those developers who have worked with good code / design patterns, etc. I don’t claim to know anything about it… because I’ve purposely stayed away from it my entire career because I have seen what problems and code this thing requires you to manage and put out in past jobs that used it, including 2007/MOSS.

Oh, and try to unit test SharePoint with proper Unit Testing without having to install the damn server and ways to test it. Have fun with that.

So what’s the problem? Why is it so hard to unit test SharePoint applications?

"This is the kind of stuff that really makes unit testing a turn off for me"

Looks like a bunch of "FUN FUN" weird ass code just to Unit Test. Oh SharePoint

Fun, Fun, and more Fun

Enough said, and this is my opinion and I’ve seen environments use this pile for enterprise based applications internally and externally and it was just a huge boiling pot mess of code, errors, and just weirdness to support this beast.

Bye the way on the right nav, there is a SharePoint Poll. Please take it.

Cheers & God Bless to JQuery, Design Patterns, ASP.NET 3.5 MVC, good ORM, Code that is Unit Testable (without barriers), and the rest. Down with SharePoint as an “end-all” solution.

Share this post :

Print | posted on Saturday, November 22, 2008 12:10 AM

Comments on this post

# Developer Poetry Series: SharePoint How Sad Are We

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Left by DotNetKicks.com on Nov 22, 2008 12:36 AM

# re: SharePoint How Sad Are We

You are right about the unit testing, but as for the rest, SharePoint is fine once you know what you are doing. The problem is that the learning curve is long and steep and the tools/docs from MS leave a lot to be desired.

That said, I've worked with a lot of enterprise application servers and they are all hard because they are all big. And, they all require you to understand a mess of underlying technologies + a big 'ole platform.

JQuery, MVC, etc. are all easier because they are tools whereas MOSS is a big machine. The same is true of SAP, the Oracle E-Business Suite, WebSphere, Notes, etc, etc, etc.

I don't want to come off sounding like an apologist, because the tools from MS are very sad. However, most of the bad implementations out there were simply built by people traversing a learning curve making it up as they went along without the benefit of a community of elders standing by with ready made 'this is how you do X' posts to copy from.

Left by Asbestos on Nov 22, 2008 10:15 PM

# re: SharePoint How Sad Are We

Guess what, I'm not looking for a learning curve that deals with proprietary code, bugs that I can't debug easily using standard tools. I like when I can just code and get the job done without dealing with proprietary crap like SharePoint. What's the point.

Left by expresso on Nov 22, 2008 10:27 PM

# re: SharePoint How Sad Are We

>>>JQuery, MVC, etc. are all easier because they are tools whereas MOSS is a big machine

It's because it's code. When you use good OOP, design patterns, etc. then you can do whatever the business wants, even quicker in my experience. And I don't have to worry about x limitation or hack to get around some stupid weirdness a system like this imposes on me. THAT'S why straight up custom OOP development using plain Vanilla Visual Studio provides much less pains and issues to deal with, especially when you already have a good development team & standards period. Also, code generation helps to speed this up.

Solid code wiht good design patterns, etc. are ultimately going to save you in the long run. At least I'd much rather have a very open architecture than a very closed architecture that pushes me out of code to solve it's issues or limitations.

I don't have to deal wtih the BS that SharePoint or MOSS imposes on my as a developer and I just get the job done even quicker because I can code quality code and reuse in my applications with no weirdness, strange code, or other in such a strange development environment such as SharePoint's. You have to log into a virtual development environment that's heavy, bloated, and a pain to manage.

I like having Visual Studio, my code local, and pure development. That's the best route and most flexible route going forward and I can handle any business requirement without the hassles long term of a beast like SharePoint that will ultimately slow me down anyway due to the configuration pains & time to manage that on top of figuring out quirky ways to code with the API and much more...you name it, I could go on and on with that.

I've been on teams that have gotten functionality that does not even belong in a beast like SharePoint done 5x as fast using good OOP. I have seen SharePoint environments and they are just bloated with strange configuration issues, code, and continual reliance on 3rd party plugins & problems with those as well as reliance heavily on consultants because the thing is such a pain in the ass. Who needs it?

Left by expresso on Nov 22, 2008 10:30 PM

# re: SharePoint How Sad Are We

Meh, I think my skills with all those tools you are talking about are as good as anybody's, but I also know most of the MOSS platform very, very well.

For most apps that are a good fit for MOSS I guarantee that in a race, I will finish in 25% of the time that I would with a bag of tools and an empty solution.

I also promise that because I actually know what I'm doing, other people can maintain it.

I think there are a lot of shops that are not willing to invest in or account for the fact that the learning curve is there and I know that the MS sales folks, by evangelizing the power-user experience, do a shitty job preparing people for the fact that there is a lot to learn. So, some manager buys it and taps some poor S.O.B. to do the implementation without making sure they have what they need.

That said, neither the product nor the API are crap, they are just very big. And, there are some parts that do need serious improvement. But, there is a reason the sales guys can show off those killer solutions to open up the CIO's checkbook; the people who built said solutions actually found the time to learn the platform.

You are right that full blown custom code augmented with your favorite libraries gives minimum impedence. You are also right that it's easier to learn: you get to pick and choose which parts to use. And really, the core of jquery (not the gazillion community mods) plus all of ASP.NET MVC might be 5% of the total MOSS codebase (if that).

But, I think you are quite mistaken about overall time from concept to production and you also (seem to) discount the value of the consistent UI, security model, farm management, and other features.

Left by Asbestos on Nov 22, 2008 11:16 PM

# re: SharePoint How Sad Are We

Well fast is also an issue. Too many IT departments want things done too fast. That leads to buying solutions that can "do it all" and I just am not down with that because they usually end up in a mess and like I explained, not standard OOP code that I can just open up VS with and use whatever I damn well please.

If you like MOSS more power to you. But I like to be able to code standard code and deal with standard development environments as a developer who is expected to deliver quality testable code on a timely basis.

I'd rather my learning curve be about figuring out standard OOP code than having to figure out that on top of using that over a very bizaare proprietary API and pain points it also introduces in MOSS as stated by many.

When I say API is crap, I mean it's bizaare. You have to know about all types of weird things to get the code working, and weird ways to work with the code. I don't have to deal with this in vanilla .NET. Also, I'd rather struggle to learn something that I can use across the board such as my C# skills without having to learn that within an API such as SharePoints which introduces all sorts of things that will slow a developer down. One being just figuring out how to talk to the different parts of SharePoint and the simple facts that you cannot do what you can do in a straight up Web Project or other type of .NET project such as for example being able to change the site masterpage is just limitations I feel is ridiculous. That's just one example, lame but true and it goes far deeper than that. I do not want to work in a virtual development environment.

>>>But, there is a reason the sales guys can show off those killer solutions to open up the CIO's checkbook

Because a sales guy persuaded a CIO to buy a huge beast, is a poor argument. That's precisely the problem, CIOs making those types of technical decisions.

But I don't want to argue again, I've made my point and as well you so I have to respect that.

Left by expresso on Nov 22, 2008 11:20 PM