Jeffrey Palermo [MVP]

Man I couldn't agree more!

SharePoint (which I've used for the past several years) is the largest pain in the neck I've ever seen from MSFT. Out of the box it works fine most of the time, but it's just way too cumbersome to even think of as a development platform.

Jeff

This is why anyone with SharePoint on their resume can command insane amounts of money for consulting. I also hear that every license comes with a bed of hot coals to walk on and a pitcher of shredded glass to quench your thirst.

I worked with Sharepoint and share your comments.  

I had to have a VM setup with server 2003 on it, etc.. to code

The experience was horrible.  Trying to modify the templates was painful, etc... documentation was horrible.  The server portal part vs. the team sites, it was ugly.

MS has alot of work todo on building server software for modification.  (CRM as an example).

It's another example of a hyped marketing job by MS making everyone think how great it is.

Because you have to develop in a virtual macine, that's what classifies it as a bad development platform? Seems like a real myopic view. And always connected? Show me an app that leverages a DB that works disconnected. SharePoint is a web app with a DB background. Would it be nice to have a "Pro" version that runs on Vista? You bet (won't run on XP because of the lack of application pools).

The product has come a LONG way since v2/SPS 2003... WSS v3 / MOSS 2007 is a much better platform. Does every app blog in SharePoint? No. But it contains a LOT of stuff you have to normally build from scratch. Navigation already setup, a security model, search OOTB, all the plumbing for the Web Part framework, and plugin model? Oh... and it hosts WF and provides all the services necessary for WF as well as provide a human aspect to it? You can DEFINATELY make a case for it to be a development platform.

Is there work to do to make it a platform? You bet... how about a real roadmap? What about REAL development tools? How about some real guidance from Redmond on SharePoint dev in true SDL processes. But to write it off this easily... bit short sighted (especially with the cases put forth here).

Over hyped? Really... so that's why it's the highest growth product ever in the history of the company and closing in on $1B in sales for the latest version in just a few months from now? That's ALL marketing hype with the other portal solutions and other content management applications out there? Um... I think business decision makers are a bit more savy than that.

-AC

Jeffrey (and others) - sorry but what you are experiencing are teething pains. I consider myself as hardcore a developer as the rest of you, and I think SharePoint is an awesome development platform.

Jeffery-

I totally agree with your point about shared database connections with your developers... I always advocate SharePoint developers run in fully isolated environment in their own VM... 100% self contained. It's fully possible to do typical isolated development within the same way you do with ASP.NET in SharePoint.

I do think it is a good development platform. Respectfully, simply discounting it due to the fact you have to run a full SharePoint install in a VM on each developer's machine is just a really quick judgement.

BTW, you don't have to develop IN a SharePoint environment. I commonly develop in Vista, test it using unit testing, package stuff up, and move it to a central build server to do integration testing with other components. A good bit of development done within a major systems (which SharePoint is) is done this way.

BTW2 - yes, you can be sure I provide my feedback in this area. Don't get me wrong, there is plenty that could be done, but tossing it out like this... well I've said my peace. :) It's like saying "forget Silverlight... I've got to jump back and forth between two apps for dev? Arg... that's not a good story." :)

Man, I just had to respond to this . Jeffrey Palermo thinks that SharePoint isn't a good development

Here's the deal, SharePoint 2007 can be, and is used as a platform for enterprise applications. Where it excels, is in its ability to tie several parts of a Microsoft based enterprise together. That being said, I think the biggest downside to using SharePoint as a dev platform is some of the very reasons you point out.

SharePoint IS difficult to get ramped up in. And, it does take a bit of an investment into powerful machines that can support robust VM's. This is in fact the ONLY way to go, and allows for almost everything you complain about. I ONLY run Vista on both my home and work machine. BUT, I am now reliant on having several Win2k3 VM's that I use for development. In some ways, this is interesting in a good way. My PC operating system is now not filled with dev tools and running processes like sql server.

P.s. I will often do a portion of my coding in notepad++ though I admit that having SharePoint Designer and VS are pretty much a requirement (put 'em in your vm).

Jeffrey brings up some good points regarding what makes a good development platform, but I would argue he missed some of what I consider the most painful parts of the MOSS development story.  

Ever tried debugging a Sharepoint web part in w3wp.exe?  After a minute or two, the SP object model times out or something, and everything is null.  And the web application hangs until you fire off an IISReset.  What the heck is up with that?

Combine poor debugging with a poorly documented object model, somewhat unclear deployment practices, and top all that off with the overhead of having to develop in a VM, and you have yourself a great recipe for frustration.

My advice to any developer lured by the riches of the current demand for MOSS developers is, just don't do it.  Your sanity just isn't worth it.

I am working on a MOSS 2007 project.

Here are some of the things we did to make the experience less painful:

1) Everyone has his/her own Win 2003 server as a development workstation with a private Sharepoint instance.

2) We created a simple, fast build-target ("QuickPatch")  to quickly update the code on the local developer machine without going through the complete build/deployment cycle. This deploys the assemblies directly to the ASP.NET application.

3) We put everything into source control and set up scripted build and deployment. To do this we bundled our app in Features, Site Templates etc wrapped up in a Solution file. This step has very poor tooling and documentation. We used a mixture of msbuild and powershell scripting to do this.

4) We have created some ordinary ASP.NET test pages that can run a lot of our controls and application outside of Sharepoint. The UI people like this for writing legacy code (code-and-fix development).

5) The UI/Sharepoint stuff and the main application is decoupled so we can run our unit and integration tests without Sharepoint

6) Additionally we use Watir/Watin scripts for end-to-end integration testing.

Overall experience is that there is a lot of friction. Some of it can be reduced by scripting etc.  This makes it tolerable - not good.

My biggest issues with SP is that it relies heavily on the wretched ASP.NET API for its GUI stuff. It would be much nicer to have something less coupled and more testable.

It's all old news. SharePoint as a platform rocks, but the tooling is immature (the polite way to put it). MS knows this and are working to improve the situation over time. It will obvioulsy take quite some to come close to the experience for regular .NET/SQL dev.

Being negative won't help anyone, being constructive on the other hand...

Check out the following posts

www.harbar.net/.../quotTest-Drivenquot-SharePoint-Development.aspx

www.harbar.net/.../Office-SharePoint-Server-Developer-Edition.aspx

I am surprised at the comments from Andrew and Sahil.  Sure, people have figured out how to make MOSS sing and use it daily as a development platform.  But then again, people also found a way to write programs using a bunch of paper punch cards, that didn't make the experience easy or pleasureable.  I think Andrew and Sahil are missing Jeffrey's point which is not a discussion of power or capability, but rather "approachability".  Any dev environment that puts up as many barriers to entry as MOSS is unnecessarily limiting its market.  Just think how much better the sales could have been if more of these roadbumps were removed.

I could not agree more. I spent a couple of weeks trying to get a Sharepoint proof of concept working. Something which would have taken a morning in ASP.NET was still not 100% after two weeks messing about with InfoPath 2007 and SPS. No documentation, no samples (this was Feb 2007), no help, nothing. It blows.

Joe-

I do get Jeffery's point.... but saying something isn't approachable does not make it a bad development platform. What make sit a bad platform? Bad architecture, no ability to change how things work or provide certain hooks (like 2nd generation SharePoint)... those are the types of things that make something bad platform.

You can make the same case with WCF, WPF, AJAX... any technology. There is always going to be a bit of a learning curve. MSFT even provides a VHD of a fully configured MOSS install with VS 2005 and all the other stuff included as trial ware. There are TONS of posts on the blogsphere showing how to setup a dev machine... etc. "But why do there even have to be posts showing how to setup a dev machine?"

SharePoint is a server product with TONS of options for customization, extensibility and value add. No matter the application, when you hook into an app, it takes a bit getting used to.

So I want to build add-ins for Visual Studio. Is it easy? Nope... because I need this and that and have all this work to do just to get my environment ready to build a plugin.

To me the issue isn't with SharePoint, it is jumping into working within and integrating with platform unlike pure ASP2 development where you building from the ground up.

I think Martin hits the nail on the head:

"My biggest issues with SP is that it relies heavily on the wretched ASP.NET API for its GUI stuff. It would be much nicer to have something less coupled and more testable."

The more an application depends on System.Web the harder it is to develop, debug, test and sometimes most importantly, re-use the services it provides.  I've run into this problem numerous times lately.  

I also find it interesting that even folks here that are betting their careers on SP aren't  arguing that it is easy to develop with.  

That's the point here, I think.  How easy is it going to be to bring a new developer into the mix? How much setup is there?  How about maintenance down the road?  If something goes wrong and the primary dev team is long gone, does the person tasked with fixing it have to cut new teeth for weeks just to fix bugs?

You hit the nail on the head Jeffrey!

I largely avoid getting involved with SharePoint projects because I have 2 under my belt and I don't want to make it 3.  I'd rather build something from scratch that does exactly what I need rather than *settle* (and you _are_ settling when you go with sharepoint as an application platform) for a product with a small set of features that solves 70% of the problems, but is vastly difficult to extend and tweak to make it work the way you want.  In the end you might get exactly what you wanted, but you probably spent the same amount of money on the Sharepoint XML Hacking (look, no code!) than you would on a solid team of experienced .NET developers.

Let's get our terms straight.  There's the "development platform", and then there's the "developer experience".  It seems that Jeffrey is (rightfully) frustrated with the current state of the art with regard to the SharePoint developer experience.  But to say that SharePoint is not a development platform is way off the mark.

Consider IIS as a development plaform for building Web applications.  Whether you build the application using Visual Studio or notepad, IIS as a "platform" simply provides the API and other services needed to get the job done.

So the first requirement of a development platform is that it provide the essential services and interfaces to build applications.  SharePoint does this very well.  Is it challenging to configure a development environment so that the developer experience is enjoyable?  Yes it is.  But that challenge is arguably a manifestation of the inherent challenge in building collaborative applications in the first place.

Brenden-

"If something goes wrong and the primary dev team is long gone, does the person tasked with fixing it have to cut new teeth for weeks just to fix bugs?"

You can't count that as a shot at SharePonit... that's true with any application. Just yesterday I walked out of a client who wants to hire a contractor to take their ASP intranet -> ASP.NET. So what happens if there's a bug down the road? They don't know ASP.NET, so what's the ramp-up time? Please... this is an industry thing, NOT a SharePoint issue.

Ben-

Not every application should be built on SharePoint... no one is advocating that (no reasonable person that is). If they are, it's the classic "if you have a hammer, everything looks like a nail". However, take something like a knowledge base, and I can guarentee you can build it faster in SharePoint than in ASP.NET or whatever else you want to build beacuse so much of the infrastructure is there. The navigation is there, a security model, plugin model, customization, CRUD screens for modifying data, locking data down by user / group, personlization engine, notifications, RSS feeds, etc. All OOTB.

John hits the nail on the head.

aconnell:

Sure, this is not JUST a sharepoint issue, but when the ramp up time is harder with sharepoint, as it certainly is, it's a BIGGER issue with sharepoint, than it would be with other technologies.

This may have already been said, but it is important to note that developing SharePoint applications IS ASP.NET development with another few object models.  There aren't as many tools available (though, we are quite spoiled with the available tools for ASP.NET), and there is a bit of a learning curve, but SharePoint is gaining a lot of momentum as an application platform.

Brendan-

Respectfly disagree. Many of the topics people struggle within SharePoint are not SharePoint specific. For example: CAS. Most poeple don't mess with it in ASP.NET apps (Full works fine, right?), but beause it's heavily leveraged in SharePoint, people associate it with SharePoint. Same with server control development... is that a SharePoint issue? Nope... not at all.

I agree.  Sharepoint as a dev platform is, and I will be kind, oversold a little bit.

With infopath - it gets even worse though.  Don't get me wrong - for certain kind of quick hit solutions, it is ok.  But should you need to "leave the box", so to speak, and optimize something (i.e. say, make the file upload control render differently on the resulting web page) - the abstraction leaks more than the titanic.

The scary thing about infopath+sharepoint is that it presents this view that writing apps is easy - which at a surface level, it can be.  The minute you need to innovate in the UI though, it can be a real pain.

(finally changed my name from aconnell > Andrew Connell... didn't realize it wasn't doing that originally, my bad)

Aaron-

Oversold? I don't see Microsoft really pushing it as a development platform for hosting custom applications at all. In fact, that's been one of my biggest compliaints to them. There's minimal guidance on MSDN, TechNet, in the articles and such. Anyone talk about SCM integration or SDL with SharePoint on http://*.microsoft.com? Nope... the only official stuff you see comes from the community.

Suffice to say the whole InfoPath+SharePoint thing is a painpoint that many have hashed out... quick search of the blogs will result in a few posts.

While SharePoint is indeed a big, complex product, most of the complexity is a side effect of the fact that it is so feature rich.

Sure, its not as simple as going to Visual Studio, saying "new web project" and starting hacking out code from scratch. I used to do that 10 years ago. I've lost count of the number of times that I've repeated pretty much the same code on every application. The nice thing about SharePoint is that I actually don't *have* to develop that much on it.

I have some master pages, page layouts, CSS, etc. which I can develop in whatever IDE I choose. They are after all just .NET pages... If I really want to get some tight integration with SharePoint, I can load them into SharePoint Designer.

Apart from that? Once you start to build SharePoint applications and realise that navigation, content aggregation, data storage / manipulation, workflows, security, profiles, audience targeting, search, forums, wikis, blogs, rss etc etc. are all there already, you start to get some really compelling metrics on the difficulty of building applications.

I'm not saying it's the only game in town. There are instances when SharePoint is not appropriate to the project - do you really need SharePoint for a tiny, static website? Almost certainly not.

Aaron's comment that you need to be careful when you step "outside" is correct. It can sometimes be challenging to work through modifications to existing functionality like InfoPath Forms. But at the end of the day, its just a .NET application. You can build a User Control in Visual Studio and deploy it in much the same way that you would with any other IIS application. Yes, you have to be more careful with CAS, you have to apply best practice to get things to work, but that's no bad thing, imo.

I sold this to my company based on the fact that our time was better spent actually writing cool apps to solve our clients' business problems, rather than building yet another control to aggregate content or expose something as RSS... it was a learning curve, but it was worth it.

I'm surprised no one has mentioned the license costs yet. As a SharePoint guy, I'm somewhat appalled that every developer must have their own licensed copy of Windows Server, with some flavor of Office also available for testing. All this may or may not be covered by some flavor of MSDN subscription, but compare this to vanilla ASP.NET. Yeah.

We're sticking to the development environment in this discussion, yes? Further points:

* Effective automated testing is difficult.

* Deployment is difficult.

* Debugging/examining the logs is painful.

I think all the MVPs mentioned it above, and they're in agreement: no one's defending the current state of SharePoint tooling. It's a definite pain point.

BUT, what the MVPs are vigorously defending, is SharePoint's viability as an application development platform.  THIS, my friends, is a different subject entirely.

On this OTHER subject, I've found this post by Oren Eine interesting--he's working with Microsoft CRM, and has a lot of complaints that do apply to SharePoint development as well:

www.ayende.com/.../Developing-on-Microsoft-CRM.aspx

Peter-

Not to come across to attack your post... but like my others, I'm trying to clarify the view that many non-SP types have looking at the SP world as I think many of your points can be addressed.

Cost? Sure... it's a server product. But you can get WSS which is included in the cost Windows 2003 Server... something you need even if you are doing ASP.NET hosting. How to address it for developers? MSDN license. You have to do that for Visual Studio too (except the Express editions). MSFT even offers a 180day eval VHD file completely installed and configured with SharePoint to save you the time of downloading and configuring everything.

Automated testing is not difficult... it is no different than an other Web app with a DB backend. As Rob said, SharePoint development *NOW* (not in the v2 days, only applies to the v3 days) is just ASP.NET development. All your existing tools work just fine. Personally, I use MbUnit for virtually all my projects.

Deployment is difficult. Have you seen "WSS Solution Packages?" This blows away anything that ASP.NET has... even in a load balanced farm, I can package everything into one file and have it all deployed to all servers in my farm at a scheduled interval... making changes to the web.config, deploying assemblies (even to the GAC) and EVEN recycling IIS if necessary. Oh... did I mention you can retract it too and undo all that?

Debugging the logs is painful. They are just text files... just like when we have to debug HTTP issues in the W3SVC logs. But better yet, I can throttle the level of errors that are included in the logs... even on a dev box making the logs "verbose". Don't like looking at text files? Check out www.codeplex.com/features and get the free LogViewer.wsp.

I will definately agree wiht the tooling comment. Today, it sucks... plain and simple. The only thing we have is the VSeWSS which leave a ~lot~ to be desired (v1.0 was a complete embarrassement that promoted horrible coding practices and hid so much from the developer). Rest assured, they know this and the story will get better. Just takes time.

To Oren's comment about source control... it's totally possible to have full integration in a SharePoint project (I use SubVersion for all my SharePoint stuff and it works great)... the problem is lack of guidance on the subject. See this post on my blog about this subject (www.andrewconnell.com/.../5451.aspx).

Microsoft "sells" SharePoint as a development platform through the "Office Business Applications Developer Portal" and uses OBA RAPs (Office Business Application Reference Application Packs) as examples of how to implement line-of-business applications on the SharePoint platform.  Here's the link: msdn2.microsoft.com/.../aa905528.aspx

I've been kind of chuckling to myself while reading this post and these comments.  I personally bet my own software engineering career on SharePoint back in 2001.  Through the wonders of simple supply-and-demand economics, my salary has never looked back.  In fact, it has increased exponentially.  To all the young developers out there considering whether or not to tackle SharePoint I would say yes, the SharePoint SDK is pretty expansive, and yes the learning is a bit steep.  Like just about any else worth doing, it is a little bit hard to get started and a challenge to keep up with SharePoint.  But, I can tell you that SharePoint as a development platform has come a long, long way since 2001, and MS continues to make investments/improvements.  The number of third party vendors creating products for SharePoint is growing like wildfire.  The SharePoint developer community grows daily.  Developer purists want to complain about how TDD isn't there yet or how the development toolset is weak, but the fact is that SharePoint does a great job fulfilling many business needs, and it is going to be around for some time to come.  If you are up for the challenge, learning to develop on SharePoint will pay off.  If not, then do something easier but, to paraphrase Achilles from Troy - "no one will remember your name".

Sharepoint is an awesome content management platform that integrates well with Office.  

It is NOT a viable alternative to custom ASP.Net sites or applications and in its current form is about 10 years behind the current set of web development tools.  The fact that it does not allow changes to the SP portal itself to be checked into Team Foundation Server (or any reasonable source code repository) in order to synchronize web part and custom work flow development with Visual Studio developers should be a red flag that catastrophe is just around the corner.

If the out of box functionality is useful to you (and it is to many organizations), use it.  Don't try to turn Sharepoint into something its not.

The current crop of MOSS 2007 consultants consists largely of Sharepoint admins -- folks who are not developers and who do not truly understand the issues behind developing a scalable application.  I see Sharepoint as falling more under the domain of network admin types than application development.

It has already become evident to many shops over the last six months what SharePoint is and what it is not.  It might evolve to become a viable application development tool, currently it is not even close.  Yet it remains the best choice out there for quickly throwing up an intranet portal.

osc1-

"years behind the current set of web development tools"

That's way off base... you just put it back int he Visual InterDev days. Completely not valid.

"[no source control for custom workflows or web part development"

Again, not true. You can save the changes you make to a Web Part in the browser (ala editing the properties), export it to a .webpart file (XML) and save that to source control. The code to develop Web Parts or workflows is done in Visual Studio... that integreates well with TSF as well as other SCM's.

"The current crop of MOSS 2007 consultants consists largely of Sharepoint admins"

Again... offbase. Try attending a single national conference or look at how successful the SP development publication business is. Last I checked, they have to have customers, and a SIGNIFICANT amount of content is developer focused.

You have obviously dismissed the product without taking a good view of it.

The real thrust of the piling-on around SharePoint seems to miss a critical point:

Product adoption.  The adoption rate is too big to ignore. Any of the developers going to a client who has purchased/considered purchasing MOSS and telling them this should just be a .NET app because its “too hard for us to program against” isn’t asking the bigger questions around leveraging Windows/MSFT investment that these customers are working to achieve. ROI on the EA dollar is a HUGE reason to find as much value in the platform and focus on business value and opening up access to other applications within the common [highly customizable]  interface of MOSS. The reasons aren’t just great [technical product] Marketing by MSFT and the SharePoint team in particular but one of how many custom application projects (winapp or webapp) actually get abandoned, orphaned or stagnate due to the current trend of outsourcing highly skilled dev oriented projects.  

I think I will like SharePoint once all is said and done, but right now I'm encountering so much pain I'm questioning if it's worth it. Reading the Technet Forums, I found this thread about "how long did it take for you to figure out SharePoint Workflow"--it's fascinating because everyone in the thread is lamenting the difficulty of getting up to speed.

forums.microsoft.com/.../ShowPost.aspx

While Jeffrey Palermo in the original post didn't mention it in his "pain list", this is my #1 problem with SharePoint development--SharePoint is too painful to learn.

It wouldn't be such a bad thing if it were "just" missing tools--the problem is that to work around holes in the tools (deployment!), I'm bouncing between the Workflow book, the SDK samples, the three search engines (Google; Technet forums search; Google Groups), and the Workflow whitepaper from the SharePoint team blog. Note I didn't mention MSDN as a resource.

So it's the documentation, too.

Combine the holes in the toolset with lack of documentation, and you end up with a lot of developer pain.

And yes, I was thankful for the new articles and content the MSDN team posted in the last SDK update, and I will continue to be grateful for any and all content they post in the future.

I think that the biggest issue with SharePoint development is that it has a significant learning curve and that right now documentation and best practices are hard to find.  There is a lot of documentation, but as with most new products it isn't well organized.  

We've found that at first SharePoint doesn't look like a good platform for development as it takes a large investment in time in order to start seeing returns.  Setting up your first SharePoint Dev project takes almost as long as the project. But once you understand the way that SharePoint works and how to structure your development you begin to be able to take advantage of all the features that SharePoint has to offer.

Andrew I think you missed my point about source control.  Yes, a SP developer could take the .xml from a web part and check it into any source code repository he wants to (lets say TFS).  He could also make changes to core.css or default.master and manually go through steps to check that into TFS, if he wanted to.  

But if another developer is making changes to assemblies in Visual Studio for example for efficient data access (the business data connector is not efficient for large amounts of data), or making changes to a web part in C#, there is nothing to synchronize the changes being made in SP with the changes being made in the primary source code repository.  They inevitably get out of sync.  I recently had to deal with a client who had a very costly (in terms of man hours.. we are talking tens of thousands of dollars) mistake occur because the changes occurring in SharePoint got completely out of sync with the development going on in TFS.  This can be worked around with a mind-boggling amount of hair-pulling manual processes, but software development and version control has come so far, why do we need to revert to stone age techniques that require us all to work seven day weeks?

Aside from the out of box functionality that SharePoint does well, 99% of the development tasks that you would want to do with SharePoint can be done with a fraction of the manhours in ASP.Net.

Peter-

I agree with you on workflow... it's too damn hard to build and integrate workflows in SharePoint. Have you read Ted Pattison's Inside WSS by MSPRESS? It's ~the~ book everyone should start with.

osc1-

I don't understand your source control point. You say there's no way to update the assemblies in the production box from what you're doing in the main development line? There most certainly is... it's called WSS solution packages (WSPs). This is like SharePoint's own little installer (MSI) framework. It can update assemblies in the site's BIN directory or even shared assemblies in the GAC. Best part is it is completely automated... nothing manual about it.

If multple projects are dependent on the same assembly, then you have to manage all of them when you do updates. Nothing special about SharePoint there... that's just general development.

"99% of the development tasks that you would want to do with SharePoint can be done with a fraction of the manhours in ASP.Net"

Respectfully I completely disagree 100%. Assuming it makes sense to build an app in SharePoint (a specific app), you can do it faster than you would in ASP.NET. Case in point, just this week with a customer we built out a site in a few hours that the team had been working on for a week and didn't make it nearly as far as we did in our workshops.

IF development in SharePoint 2007 is hard, try developing in SharePoint 2003. When I need to create a security trimmed interface for SharePoint 2003, I have to look at thousand and thousand of lines to do that. Now, SharePoint 2007 provides that for you, and allows you to extend security trimmed elements easily.

When I have to create additional custom list, I have to make copies of their files, and modify from there. Deployment, maintenance are nightmare. Not to mention, lack of documentation, and I'm learning and banging my head by myself. Now, I just need to define features, and a few xml files, I'm more or less set to deploy it to entire farm.

Sure, dev experience may not be that great (Hey, I'm not happy with Visual Studio's web project. I rather start a code project for web application), but give Microsoft time, things will evolve. And to their credit, dev experience is improving!

The best part is community is growing like mad, with lots of blog posts giving much better documentation with real world experiences! Sure, I would love to see Microsoft improve their documentation, dev guidance. But source control and automated testing, builds are not impossible... MVPs have mentioned that source control, automated testing is possible... Why don't you try those out first?

My team which has implemented this project, community.sgdotnet.org/.../SharePoint-as-an-application-platform_2E002E002E00_.aspx, have java background. I don't even need to guide them in setting up the SharePoint project, and they have source control set up for themselves!

All products have learning curve. Its whether you embrase that fact, or you winne about it.. But the truth about SharePoint adoption is

1. Customers are interested. There are companies set up just to deliver SharePoint, and these companies have resource issues, and are pushing projects away.

2. SharePoint developers are in demand.

3. SharePoint can now be a viable app / dev platform when appropriate. And when used correctly, dev time is shorten and less expensive. I'm not going to develop a Cab Dispatch System on SharePoint. But there are factors that is stopping this, but definitely not the above!

Oh boy, if this debate isn't up there with "my Mac is better than his PC"... I have to put my 2 cents worth in all the same...

Coming from an ASP.NET devlopment background and now working as a SharePoint architect I cannot disagree with you more on your statement that SharePoint isn't a good platform.  

ASP.NET IMHO isn't really a mature platform by today's standards.  Sure you can build any web site you care to mention, but you have to do all the leg work yourself.  It's the same with every ASP.NET job I've had - create an Enterprisy web site with dynamic navigation, crude content management and document storage.  Well blow me down with a feather if SharePoint doesn't already do all of that, only much better than any home brew I've ever encountered.

In today's business environment executives want information systems fast, in a matter of weeks, with all the CMS aspects ready to roll. Why? Because next week business has moved on and they need another information system.  Custom developed ASP.NET web sites just cannot stand up to that sort of demand.   SharePoint can, and developers can met the needs of their clients/employers by using SharePoint as a stable platform to build on.

Think about the blog sphere - a few short years back blogging was for geeks only - most did not use blog engines, and those that did used a system put together by a developer in his/her spare time.  Now, if you want a blog do you install a build software?  No, you pick from one of the many blogging engines out there for free and start typing. Imagine where the blog spere would be today if we said "hold on, we need 6 months to write a new engine" each time someone wanted a newer type of blogging site.

Disconnected development on Vista/XP - I see your point there, but then again, what's wrong with virtualization?  When on the road I use a single Virtual PC instance which does fine on my middle of the road laptop. In the office I have a whole set of virtual server instances for writing code against AD, SharePoint, SQL Server, and Exchange - if you're gonna develop enterprise, then you need the whole suite of servers anyway.  ASP.NET.... well let's face it,it's not Enterprise ready OTB.

Andrew,

No, you're either not reading what I am writing carefully enough, or I'm not making a strong enough effort to communicate it.  Let me try once more.  

You said:  "You say there's no way to update the assemblies in the production box from what you're doing in the main development line?  

(That's not what I said at all.  I am not talking about assemblies here, I am talking about source files.  That is one of the biggest problems I see with SharePoint folks, they do not understand source code management.  I am talking strictly about code-behind files here, and the other files that constitute an assembly -- not the assemblies themselves).

But, then you said....

"There most certainly is... it's called WSS solution packages (WSPs). This is like SharePoint's own little installer (MSI) framework. It can update assemblies in the site's BIN directory or even shared assemblies in the GAC. Best part is it is completely automated... nothing manual about it."

This further confirms to me that you are confused between packaging and deployment (MSIs and what not, what assemblies go where, what gets GAC'd and what stays local, and so forth) and source code management (the raw .cs and .aspx files that get checked in and out of TFS).

Sharepoint offers ABSOLUTELY NO SYNCHRONIZATION.  I will say that word until it sticks.... SYNCHRONIZATION....  between the development that occurs in SharePoint (which goes in the SP database), and the source code for the custom web parts or custom business objects that are required to provide truly scalable data access (which go in TFS).

I am talking about synchronization here.  I have had so many SharePoint consultants pass by me with the typical evangalism, but when I get them in a room with a group of people who are really paying attention, they break down in a cold sweat over this topic, as it is critical to the development process.  Without proper source code management, you have a ticking timebomb going on with any sort of reasonable development effort.  If you have two completely disparate source code repositories (SP and TFS in my example) which are completely disconnected, and do not have a way to synchronize source trees, it is a development process destined to self distruct.

Any software engineer that has a true development background knows what I am talking about here.

Rob Garrett,

Depending on the type of portal applications you need, you're right.  SharePoint is the right platform for the typical organization who just needs a basic portal with (not so simple) document versioning and content management.  This kind of stuff is a nightmare to write by hand, and although I would argue that I can start with a bare bones ASP.Net application and whip up a secure, role-driven site with dynamic navigation in less than 40 hours work (as could anyone with a few years of C# under their belt), the document repository and content management features are are compelling feature that make SharePoint perfect for this.

The problem comes along when your client doesn't either wants their site to do one of the following:

1. Not look like every other sharepoint site out there

2. Access large amounts of data, or complex data structures

3. Exhibit custom behavior

4. Take on a highly-polished look and feel designed by professional graphic designers, who live in world of Dreamweaver and MacBooks and could care less about the specific .css syntax that Sharepoint requires

At this point, SharePoint completely falls apart at tasks that could be completed in a couple of days using standard ASP.Net development.

I can understand what you are trying to say here, at least I think I can. what I think people overlook is that this is only the third version of this product.  All products take time to mature.  Visula Studio itself has matured greatly, the .Net framework, etc...   I can understand the frustration of many developers since they are now so accustomed to having tools to make everything so easy.  In this world of RAD, Agile, and any other "fast paced" development tools, as soon as they have to make a bit of real effort, they say "forget this, it sucks" and move on.  OK, that is fine.  Come back later as the PG takes peoples feedback and improves things.  Maybe it weill be easy enough for you to use later.

Until then, to just uniformly dismiss it as a development platform is your own choice and you are intitled to your opion.  Whether it is "hard" to develop for or not it is still a wondeful product with tremendous potential.  The obviouls improvements from v2 to v3 show just how much SharePoint can grow, and the absorption in the market is a testimony to its power and utility in the real world.

Most things start out rough and get better. I for one will be quite proud to say "Yeah, I stuck it out through the rough times, but look at what my sweat hath wrought."

osc1,

Dude, have you seen this?

http://www.codeplex.com/CKS

Do you know that the source for the various project are checked in?

Matthew,

There are implementation of SharePoint that doesn't look anything like SharePoint at all... Below are the links...

www.hawaiianair.com/.../Index.aspx

www.sendtec.com/default.aspx

www.glu.com/.../home.aspx

www.migros.ch/.../Home.aspx

Love Kit Kai,

I am not talking about checking in.  I am talking about the problem of requiring synchronizing source code between two repositories.  If there is a solution, nobody has come close to addressing it yet.

Is there a developer in the house?

I understand your gripe that working on ASP.NET from the ground up is better than using SharePoint as a development platform.

But that was how I felt during the early days in SharePoint and I would usually argue with our architect that developing modules in ASP from the ground up was so much faster and better than in SharePoint.

Two years after, I am in the same mindset of my architect mentor and I find it disgusting to develop in pure ASP than in using SharePoint.

When you gain more experience in SharePoint, it would be interesting to see your view change.

I think osc1, you're talking about synchronizing what are called "artifacts."

I'd be interested to see what others say about this; what I've read from a Microsoft whitepaper (don't remember the name) is that they recommend everyone work on artifacts in a shared development environment. It's obviously a compromise.

I'd be interested to hear others' opinions on this--I'm considering if it's possible to 1) take a site backup, 2) unpack the site backup's CAB file, 3) split up the manifest.xml file via XPath, and 4) check portions of the manifest into source control as individual sections. I haven't found a specific need yet, so I haven't bothered trying this out, but I wonder--what are others doing about this?

Thanks Peter, I am glad someone realized what I'm talking about.  I saw the same whitepaper as you and at least as of a month or so ago, it confirmed to me that SP development is not quite ready for the type of development shop we are running here.  But yes I am talking about how, from the perspective that the source code repository (whether that is SP or TFS) is the keeper of the jewels, and with lots of daily development activity going on, the work items that are checked into TFS must be able to be conveniently and conclusively linked to their corresponding version in SharePoint.  There is not currently a mechanism to do this, and it is simply a recipe for disaster.

Also Love Kit Kai,

Those are the same sites every SP developer uses as examples of sites that don't look like Sharepoint.  But if you look closely, most of them achieve their custom look using Flash, or standard CSS techniques applied on top of Sharepoint rather than default SP functionality.  I know ITS POSSIBLE to make a SP site look customized, it's just that it is rediculously difficult compared to trying to achieve the same goal in ASP.Net.

Jeffrey should be commended for allowing both sides of this to be explored here.  Sahil Malik, who is always trying to push Sharepoint as the solution to everything, doesn't even allow blog comments through unless they meet his agenda.  It's like the Rupert Murdoch syndrome.  Very insecure individual.

Good show Jeffrey!  It is very cool that you are keeping this important exchange open and going.

Well done!

Jeffrey,

You're absolutely right, it is an IT tool in it's current form that does some things quite well.  I think we can expect future versions to better allow true application developers to extend SharePoint, but in it's current form there are only a few isolated scenarios where doing so makes sense.

Ted - now you are just accusing me of something completely untrue. If you ever left me a comment, unless it was highly inappropriate, I have always let it through.

Oh and BTW, if you noticed, I don't blog on this site anymore, but even then I rarely login here and publish all non-spam comments.

Seriously man, you're just lying here.

Salik -- as of this writing, you have zero follow up comments to your rebuttal attempt at this thread.  This means 100 percent of the comments you've received are being filtered out as "highly inappropriate" according to the definitions of inappropriate laid down by Mister Malik.  I know of at least one other person besides myself who tried to leave a response, and it was never approved.

Now you're claiming that you rarely login here, but you logged in frequently enough to post a rebuttal thread to this post, and you logged on frequently enough to read the follow ups a few days later.  Who is the liar here again?

By the way I was referring to your Winsmarts blog, not any blogging you may have done at some point here.  

Ted - I had no comments there, or I would have let them through. I wasn't even checking this thread, until someone pointed your inane comment out.

>>   I know of at least one other person besides myself who tried to leave a response, and it was never approved

I never saw those comments, did you fill out the captcha or was that too much for you too handle?

Don't lie, allright! I never got any comments.

Here is a little trick, if you leave me a comment, and it is awaiting moderation, the comment count actually goes UP. Did it go up? (Yeah it's a bug, but I have other things to do besides fixing my buggy blog engine, and arguing with guys like you).

Try leave a proper argumentative comment, and use the mouse and keyboard properly - tell me if the comment count went up, if it didn't, shoot me an email (from my site). I'll see what I can do to fix it.

----------------

I am surprised at the comments from Andrew and Sahil.  Sure, people have figured out how to make MOSS sing and use it daily as a development platform.  But then again, people also found a way to write programs using a bunch of paper punch cards, that didn't make the experience easy or pleasureable.  I think Andrew and Sahil are missing Jeffrey's point which is not a discussion of power or capability, but rather "approachability".  Any dev environment that puts up as many barriers to entry as MOSS is unnecessarily limiting its market.  Just think how much better the sales could have been if more of these roadbumps were removed.

-----------------------------------

Joe - no I am not missing Jeffrey's point. In fact, that is my biggest complaint about this blogpost, that IT HAS no point. It didn't mention anything specific enough that you can comment upon. You can't develop on XP and that makes it a bad development platform? Seriously !! First of all you CAN develop on XP, and does it itch you weird if you develop on 2003?

I still insist that sharepoint is a pretty darned awesome dev platform, Dev platform choice is not governed by "development experience" alone. You also have to consider time to market, overall cost of development, amount of custom code required, etc (see my blogpost on this).

Is the dev experience the same as .NET? Heck no! But sharepoint and other such products are built on .NET so their being behind on the adoption curve is understandable.

Is there room for improvement? Sure there is. But I'd rather see constructive and actual weightage bullets coming from Jeffrey's blog - than issues that have absolutely no weight.

So again, my biggest complaint with this blog post is, it has no substance. No points that are either specific enough, or just highly inaccurate.

SM

>>

"My biggest issues with SP is that it relies heavily on the wretched ASP.NET API for its GUI stuff. It would be much nicer to have something less coupled and more testable."

<---

See you just can't win. Sharepoint is built on top of ASP.NET. It uses all principles that any good ASP.NET app would.

Now is it decoupled? You realize that you can completely rip out the master page, and build something that is entirely decoupled. What's more, even if you choose to take that extreme route, your effort required will probably be a lot lesser than an ASP.NET app.

>>Sure, this is not JUST a sharepoint issue, but when the ramp up time is harder with sharepoint, as it certainly is, it's a BIGGER issue with sharepoint, than it would be with other technologies.

_______________________

C'mon Brendan - if "I" could learn sharepoint, anyone can :-). Especially you!

OSC ----

>>>>>>>

.... It is NOT a viable alternative to custom ASP.Net sites or applications and in its current form is about 10 years behind the current set of web development tools.  

10 years into history .. CGI? You know you are horribly wrong there.

>>>>>>>>>>>>

Source control

Completely incorrect. You can tie sharepoint to source control.

>>>>>>>>>>>>>

The current crop of MOSS 2007 consultants consists largely of Sharepoint admins -- folks who are not developers and who do not truly understand the issues behind developing a scalable application.  

I am a developer, I understand scalability. Also read the case studies surrounding sharepoint before you make a comment on scalability.

>>>>>>>>>>>>>>>

It has already become evident to many shops over the last six months what SharePoint is and what it is not.  It might evolve to become a viable application development tool, currently it is not even close.  Yet it remains the best choice out there for quickly throwing up an intranet portal.

Again, see the companies.

And seriously your organization likes an intranet that is set 10 years into histroy? ;-) TERRIBLE.

Last comment here ---

(before akismet marks me down as a spammer).

There are some valid concerns about the sharepoint dev experience. This blogpost alongwith it's comments doesn't even begin talking about them.

I'd like to see some actual recognition of possible improvements, and a suggested plan to make things work.

Does sharepoint offer a crazy learning curve? Well, there are > 40 books on sharepoint right now, how many have you read cover to cover? So please don't confuse your teething problems with a platform's capabilities.

Remember, you've been mucking around with .NET for 7 years now - you can't expect to have the same level of familiarity with sharepoint in 2 months. Be kind (and realistic) to yourself.

Whew - gotta run!!

I have no idea why is everybody thinking that SharePoint 2007 is here as some part of bespoke development revolution. Second misconception also leads people to believe that MOSS2007 is merely an upgrade to its predecessor SharePoint 2003. SharePoint 2007 is an Enterprise Content Management Platform. It’s a platform for building and developing: Document Management solutions, Records Management Solutions, Business Process Management solutions, Business Intelligence solutions, platform providing integration with various Line of Business systems etc etc. Combination of the things mentioned earlier together with many supporting technologies makes up Microsoft OBAs for relevant industries. It’s again a platform much like other competitive products on the market, such as Livelink  (from OpenText), Documentum (from EMC²), Filenet (now owned by IBM), HummingBird (now also owned by OpenText) etc etc. I could be wrong but I seriously don’t think Microsoft sells SharePoint 2007 as a development platform, because that’s not what it is. In the ECM market Microsoft is newbie so is SharePoint 2007, but it has enormous potential which will alow Microsoft to very shortly surpass its competition

With all due respect to all of you people, I have no idea what you’re arguing about, and why.

By the way, my point is:

In my opinion, Jeffrey you got it wrong from the start. SharePoint is not a platform in a way you thought that it is. SharePoint is an excellent platform and WCM  (what SharePoint 2003 is) constitutes only 2% of what SharePoint 2007 is. I come from an extensive  Enterprise Content Management background and I've been implementing ECM solutions my whole career (Livelink, Identitech FYI, Domea, K2.NET and Meridio, Global 360) as well as experienc