Why I Stick With Visual Studio 2008 for SharePoint 2010 Development

People seem surprised when I start up my development environment to to SharePoint 2010 development. The surprise comes from seeing the Visual Studio 2008 logo flashes before their eyes.

“What you’re not using the latest and greatest? How come?”

I’ll tell you why, and I’ve already given you a slight hint. “The Visual Studio log flashes before their eyes”, indicating speed. Visual Studio 2008 is lightning fast.

I tried working on every edition of Visual Studio 2010 from the early betas. Compared to the earliest versions, the RTM version seems like a race car where the old versions were various species of snail.

Despite this, Visual Studio 2010 feels like a snail when compared to its old brother. I write a lot, not just code, so perhaps my typing speed is higher than average. I always feel the IntelliSense is sluggish and just a bit too slow to keep up. I try this on massive machines as well, sporting 16 GB of ram, so it’s not a hardware issue. Granted, I run this in a VM, but I’ve never had problems with this in 2008, so I blame 2010.

The thing I’m missing from 2010 is the smart IntelliSense that searches the entire words of methods and properties. I’ve grown so accustomed to the SharePoint object model, however, that the times when I need to search for methods and properties are few. It’s nice for exploration, but not enough to warrant the slower speed.

The next thing people ask is why I’m not using the fancy SP2010 tools. I’ll tell you why: They suck.

Yeah, there you go, I used the word again. I just don’t think the hype is worth the quality of the final product.

When I meet SP2010 developers who have previously worked with SP2007 development, they all say the same thing: the tools are bells and whistles, and takes away your feeling of control. Sure, for kids, it is nice to click around to give the impression of doing stuff. Compared to VSeWSS, I’m sure it’s great.

The two developers I’ve met that used the horrible VSeWSS tool previously are thrilled, and I can understand that. When what you’re coming from is your balls in a thumbscrew (ladies will just have to imagine something extremely painful, and no, giving birth isn’t as painful), then sitting on a bicycle with a missing seat must seem like heaven.

So what do I use? I stick with trusty old WSPBuilder. Heck, the experience is just as good as it always has been and the control is rivaled by no other tool.

Despite what seems to be a rumor, WSPBuilder is far from dead. I heard that Carsten Keutmann had decided to cancel the WSPBuilder project. I wrote him asking if this was true and he said that he was just pausing to see where the SP2010 tools and community headed.

I can tell you right now, Carsten, it’s headed for disaster, but because the lack of competition. With the SP2010 tools, you’re stuck in a maze trying to get control over your project, but ending up with nothing what you expect.

So the SP2010 fanclub says: “The tools are great once you learn how to use them!” to which I can reply that, you know, even if that were true, and I doubt it, I want to learn SharePoint, not how to use a particular tool. When there’s a learning curve for a tool beyond 5 minutes, the tool is faulty.

WSPBuilder FTW! Carsten, get yer behind in gear and get back to giving us the development experience we want.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

SharePoint Designer 2010 Workflow Video Bonanza

Although it’s been far too seldom, I haven’t stopped writing USP Journal issues. Actually, I’ve been writing on several issues over the last few months, but most of my time has gone into getting USPJ Academy up and running.

The next issue, Volume 2, issue 2, on SharePoint Designer 2010 workflows, is due out next week (which would be September 20, 2010, if you’re reading this at a later time). I just got the copy-edited version back from Kim (my resident and highly skilled copy editor) and have begun the production of the final version.

The issue, I can tell you, will be massive, and I’m breaking all the previous records for amount of content. The issue itself is over 140 pages long, and I’m piling hours and hours of video content into the bonus downloads as well.

However, despite all the content that I’ve added, it’s clear that I haven’t been able to cover all the improvements of SharePoint Designer 2010. So, I’ve started to record and upload a number of shorter SharePoint Designer 2010 workflow videos to the USPJA YouTube Channel. These videos are shorter tips and tricks and stand on their own, without needing any special setup.

Here’s the first one, on creating documents as part of a workflow in SharePoint Designer:

I’ll be recording several more videos over the next couple of days, so you may want to subscribe to the channel at YouTube to get all the updates.

If you have specific requests that you’d like to see covered, feel free to drop me a line or post a comment, and although I’m not making any promises, I’ll see what I can do 🙂

All of the videos will be added to the bonus downloads for the journal issue, by the way.


Pin It

Out-of-the-Box in SharePoint – Part 2

So, the pot got stirred last time I posted on this topic, and I’ve been promising an update to several people. Now that we got the final pieces of the USPJ Academy platform in place, I can get back to doing less critical stuff.

Not that I don’t think blogging is important, it’s just that I don’t care about you.

To sum up the debate, as seen from my admittedly narrow perspective, I said that out-of-the-box made no sense because most of the out-of-the-box stuff was made by marketing people to show how cool SharePoint is and not to solve business problems. The OOTB stuff is there to sell SharePoint.

Some people said I’m mad because you can to all sorts of cool stuff with OOTB. My very good friend Marc Anderson didn’t agree with me, which of course just makes him wrong, but that’s his choice. There was also a bit of talk over at EndUserSharePoint.com and probably a few other places.

Regardless, I thought I’d clarify and expand on the previous post a bit.

Why Business Solution Development Should Be Left to Professionals

For years now, database applications like Microsoft Access have been available to business users all over the globe. Being able to store business data easily seems like a great benefit, right?

However, despite the ease with which users are able to create business solutions, quite a lot of the solutions developed in Access turn out to be incredibly expensive, unstable, and insecure. Not just that, but once the business starts depending on these solutions for normal operations, the solutions turn into critical components of organization survival.

If you are a business user thinking Access and similar tools is a great benefit at this point, ask yourself; what do you really know about the second stage of database normalization. Do you even know what normalization is? Or, how is your version management and deployment testing of these applications? How do you ensure database integrity on cascading deletes?

I suspect a lot of business users will have little or no idea what any of this means, and we’re still just talking about data management. You know, that absolutely vital part of your business, the data.

Oh, and some of you will know about data development, and be very good at it, so don’t pull that “well it doesn’t apply to all” BS. To you, however, I’d like to ask how you maintain your CAS policies to prevent damage, malign or innocent, from third-party add-ons. Or something similar.

Look, we’re not spending decades learning how to develop stable and maintainable solutions just because it’s cool. There are very good reasons why these things are important, and if you don’t understand their consequences, you will get burned.

OK, I can already hear the scream of “business users know what the business needs!” and that is exactly right. Which is why I didn’t specify SharePoint in ‘Professionals’ part of the header above this section. We, as developers, know squat about your business, or any business, really. We’re developers, we dream in languages you think only belongs in a zoo (CAML, Python, Tiger). We have no idea what goes on outside the comfort of our 24 inch monitors and piles of pizza boxes. If we see sunlight, we immediately start thinking of how to ray-trace a similar effect.

That’s why we need you, as professional business users, to tell us what you need. We can make a cat bark with the proper method call, but we can’t tell if an invoice will affect the third quarter profit margins, because we have no idea what either invoice, quarter, profit, or margin means. You are experts at that and we sorely need that expertise to build the business solutions you need.

What would you think if I, as a developer, came into your company and started putting together slides presenting your business plan to investors? There are tons of ‘easy to use, just fill in the blanks’ business plan templates available online. Since the tools are so easy to use, I mean, how difficult can it be to run a business? It’s just a matter of taking those profit things and put them where it says ‘insert profit here’ and we’re good to go.


What Does This Have to Do with Out-of-the-Box?

Just one thing before I start answering this: I have never said that out-of-the-box is bad. I explicitly said that, if out-of-the-box is a good idea, it will far more often be me, as a developer, telling you, as a business user, that you should chose the out-of-the-box tools. If you read the entire original post and not just gasped and started blogging after reading the title, you’ll see that assuming that out-of-the-box is cheaper, safer, or in any way more accessible than other alternatives just doesn’t make sense.

Mark Miller was also surprised that, since I had cheered him on during SPTechCon, I was bashing out-of-the-box and no-code solutions a few months later. I am not. What I am saying is that there is a range of topics that those solutions do not take into account or even need to take into account. There is a world of scenarios that require those kinds of solutions. That doesn’t make them scalable, secure, supported, maintainable, testable, or anything that a developer would have in their bones, but that may not be what you require.

Regardless, a great number of what Marc Anderson calls the Middle and First Tier developers came screaming that out-of-the-box made perfect sense. After all, they were able to create immensely cool things without writing a single piece of code, at least not in Visual Studio.

I have also heard an argument that developing custom code takes forever and that a developer needs a week to develop something that a skilled Middle Tier developer can do in a day. Arguments like these are just completely rubbish, as a good developer will beat a bad Middle Tier developer any day, same as a good Middle Tier developer would beat any bad developer on the same day.

If you want to prove yourself, however, try to match my friend Einar’s 5 minute demo for creating a real-time request graph.

Oh, and here’s my favorite argument, developers are so expensive that an in-house business manager (who probably makes five times as much as I do) would be better. Or, one could hire a less experienced person to do the simpler task. With the tools so easily available, everyone can make valuable solutions using out-of-the-box features.

I know that. In fact, I do it all the time.

It is just one of the tools I use, however. One technique I use very often and in fact teach as often as I can is to configure as much as possible in the web UI to get a quick prototype up and running. Then, hand the prototype to business users and let them continue working on the site until they see that they solve their current needs. Once that happens, I convert that solution into maintainable and upgradable code. Users then take over the solution and do with it what they should, namely tearing it apart and creating chaos.

That’s quite alright, because as a SharePoint developer, I need to take into account that the
environment in which I deploy my solutions may be very different when I deploy it than what I saw when I started creating a solution, or even five minutes prior to deploying the code. When the business needs change, I can write new code that takes the current situation and changes it into the desired situation.

As a developer, I never touch the production server at all, or at least I shouldn’t. Also, I cannot make assumptions because users are unpredictable. If I rely on a list for a lookup column, I cannot know whether that list definition still matches what I saw when I looked at it (if I even can look at it) or if the list even exists anymore. Is the user profile service available? Who knows? The administrator may have deleted it 30 seconds before the deployment. Again, quite alright, I take that into account when I write code.

These things are requirements of creating critical applications. It’s part of ensuring that the solution is stable and adaptable enough to cope with changes that happen both in the short term and long term. It is critical for any high-availability scenario.

That may not be your site or your solution. Not all solutions mean the life or death of an organization. If you just want to share documents, there’s no better place than Shared Documents. If you want to add a list of links to an existing site, it would just be stupid to build a deployment package to do so. Who does it quicker is besides the point (I’d win, of course), it’s just that a solution package for a task like that makes no sense.

If all you know, however, is using out-of-the-box features, then you’ll always end up using out-of-the-box features. Or, as I’ve written earlier, if all you know how to use is a hammer, then every problem looks like a nail.

I have to end this now before I keep ranting for hours, but I reserve the right to make even more follow-up posts if I like.


Pin It