Good News for SharePoint 2013 Developers: You Still Have a Job

…and you’ll get a new laptop.

Best news? You really know most of what you need to know.

SharePoint 2013 Doesn’t Change Anything

During SPTechCon in Boston 2011, I recorded a video for Christian Buckley on the one thing you need to know about SharePoint 2010. My message then was that you really don’t need to relearn everything when moving from SharePoint 2007 to SharePoint 2010.

A couple of days ago, I told Christian that if he just did a voice-over on the SharePoint 2010 parts of that video, he could republish it as my response to the one thing SharePoint 2013 developers to know about SharePoint 2013.

So, what you already know about SharePoint 2010 mostly still applies to SharePoint 2013. You still work with WSP solutions, you still have master pages, you still build taxonomies using content types, and they don’t even change that much either.

This is great news for SharePoint 2013 developers for several reasons. First, it makes the transition from developing on SharePoint 2010 to SharePoint 2013 very easy. What you already know still works. In fact, even though there are several new features and even a brand new .NET framework, Microsoft has gone to great lengths to preserve backwards compatibility.

For third tier developers, meaning those of you that spend your time in Visual Studio, you’ll be pleased to know that the Visual Studio tools also works more or less like they always have.

Of course, if you don’t like those tools, we still have to wait for Carsten Keutmann to give us a new version of WSPBuilder, but regardless of tools preference, because virtually everything that worked in SharePoint 2010 still works, the learning curve will be as smooth as a baby’s bottom.

What you shouldn’t do, however, is continue to use sandbox solutions. Or start, if you have been sensible and not used them at all. Simply put, sandbox solutions are dead, or have at least been given the last rites pending imminent departure from the land of living technology.

SharePoint 2013 Changes Everything

Yeah, I know, I’ve been using contradictory headlines a bit too much lately, haven’t I?

If nothing changes, then what is all the fuzz? Well, things that worked one way before continues to work, more or less. However, there are plenty of new things, and also some things that change. And, there’s the dreaded ‘more or less’.

Note: There’s a new interface. Not really newsworthy, now is it?

First, there’s the last paragraph above, on sandbox solutions. When sandbox solutions go away, Microsoft believes we need something to replace it, and that something is apps.

Personally, I don’t see what the deal is with apps. Essentially, apps are other web pages. Great, so now we can run web pages in SharePoint. Considering that apps aren’t really part of SharePoint at all, but instead run as completely separate applications somewhere else, it’s not really as ground breaking as some people want us to believe. Granted, there are some very cool things Microsoft has done, for example around security, licensing, and the SharePoint Store, but not enough to warrant the hype, in my opinion (which is rarely humble, by the way).

To confuse us even further, and I believe this is a huge mistake, the concept of apps now includes what we already know and have trained our users to understand, such as lists and libraries. That’s right, you’re no longer going to tell your users to add a contacts or task list, or even a document library, they’re now going to have to learn to add a contact, task, or document app. Technically, it’s virtually the same as before, it’s just that it’s suddenly a totally new thing. Everything changes.

Then, there’s the SharePoint Designer story. Have you used SharePoint Designer before? Well, it looks exactly the same, does the same thing, except now you can’t see it. That’s right, either you learn HTML and ASP.NET markup or you won’t be able to use it. There’s no visual design mode anymore, so with the exception of workflows, modifying properties, and creating artifacts like lists and libraries in SharePoint, which is still a lot more flexible in the web interface, SharePoint Designer is now gone. They really should rename it SharePoint HTML Editor with Stuff, because “Design” it isn’t. Everything changes.

Oh, but do you know why? It’s because Microsoft no longer wants you to customize SharePoint. That’s right, Microsoft has decided what you want, and they intend to make you use it their way.

I’m not joking here, I’m as serious as cancer on a cute puppy dog. I noticed this in the official announcement from Jeff Teper (almost at the end, subtitle “Great SharePoint Deployments”) on the official SharePoint blog and tweeted it. What Microsoft is now saying is that you (or really, SharePoint 2013 developers) shouldn’t modify the out-of-the-box experience, unless you have to, and then only do it well. And here I was thinking that it was recommended practice to deliver crap.

The SPYam community (which is the Yammer community for SharePoint) has had a chance to discuss this with Jeff, and he essentially confirms the message. Microsoft thinks they see that there is too much casual customization out there, much of which is done badly, so they want to take away.

Don’t mess with it, in other words. Microsoft knows best. What was formerly one of the greatest platforms for customization and development in the world has now turned into a package that comes with a “warranty void if opened” sticker on all the cool stuff.

Note: I’ve written about this previously, trying to explain what it means.

So, everything changes.

So, Why Is this Good News for SharePoint 2013 Developers Again?

You may ask why these points are good news for SharePoint 2013 developers. After all, we’re given yet-another-great-hype development model, we’ve lost a great tool in SharePoint Designer, and we’re told that our customers shouldn’t modify the platform anymore.

The latter is the easiest thing to explain from a “good news” perspective. No longer will we be burdened by clients changing what we’ve done. Microsoft clips their wings so now we can stop worrying about what happens if something changes, because we, as good developers (not the bad ones, those should stop working) are now in control. At least in Utopia.

Clients, or course, still have the need to change things, so when Microsoft takes way their ability to do so (strictly speaking they are encouraging them to not do it), they’re not scratching the itch as much as they’re tying your hands behind your back and ask you to call someone how knows how to scratch. Microsoft is looking at a symptom and tries to cure that, rather than look at the underlying causes. If customers want to customize, but suck at it, then making the customer not suck should be the cure, not covering up the want.

As for SharePoint Designer, it is a similar story. No longer will less worthy users have any reasonable chance to make their site look like they want. Either they learn HTML and ASP.NET markup or they break everything if they try to modify something. Of course, if they break it, they’ll have no chance of fixing it again, which means more consulting hours to us. It’s akin to removing the safety switch on a gun and tell people they no longer want to shoot anyone.

Finally, the fact that we have a whole new application model in apps means that there will be so many attempts at making it work that the need for SharePoint developers will skyrocket. Everyone and their grandmothers will want to have apps for everything, and we’ll be the ones to build it. Again, great news for our marketability and for our job security.

So, we’re going to be even more valuable than before because nobody else can do what we do, and Microsoft is actively encouraging our competition (meaning clients) to not get in out way. Our HTML knowledge from the 90s will finally be relevant again, and there will be so many new apps projects that we can pretty much kiss any unemployment goodbye.

None of these things, however, are good for SharePoint, nor for our clients. As such, I do hope Microsoft changes their mind.

I hope they give us back SharePoint Designer.

I hope they restore confidence in their customers and encourage them to learn how to customize rather than tell them not to do what they suck at.

I hope that you really, really consider the benefits of a new application model before you open wide and swallow whatever the hype tells you about SharePoint apps.


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

Reading Guide: USP Journal Issues for SharePoint Third Tier Developers

I got an email from an aspiring SharePoint professional that wanted to buy all my journals to learn as much as possible. I certainly appreciate the enthusiasm for learning, but honestly, not all the issues are for everyone so just buying them all and reading randomly probably isn’t going to be the best approach.

As such, I wrote him a reading guide so that he can read up in the order that makes sense. Here’s what I wrote:

I have written a blog post (it’s at as the start of a series that focuses on the path to becoming a SharePoint professional. The first article cover discipline (as in area of skill, not in mental discipline). You may want to read that when it comes out, as it speaks to your aspirations of becoming a subject matter expert.

Based on what you say here, I’m you closest to what we call a third tier developer. A third tier developer is essentially someone who works with Visual Studio to build WSP solutions for SharePoint. I recommend you read up on Marc Anderson’s Middle Tier Manifesto ( which will outline the tiers of SharePoint development.

However, practicing a SharePoint development tier isn’t an exclusive thing; most developers at least dabble in other tiers, such as jQuery, SPD Workflows, and so on. That’s fine too.

To get started with the journals, I would recommend that you start with Beginning SharePoint 2010 Development. This will be a good foundation for your further studies, especially because you are reading the journals.

Next, I would continue with Developing SharePoint Content Types and SharePoint Web Part Development. Both of these cater to intermediate skills in taxonomy and user interface development, two of the three core skill areas you’ll want to understand.

After than, if you want to continue along the content type path, I recommend first reading Content Types for Business Users (to understand their business impact on taxonomy) and then Advanced Content Type Development, to see some very cool ways of extending SharePoint into areas nobody has so far even dreamed (it’s more about understanding how to extend than any specific scenario).

If you want to continue the user interface path, I’d chill out for a while, because there is a new issue coming (time permitting) called Advanced SharePoint Web Part Development. You may also want to pick up (although this isn’t a USP Journal) my book called Building the SharePoint User Experience. Although written for SharePoint 2007, it goes deeper into how SharePoint works under the hood with respect to building great user experiences.

The last of the three core skill areas for third tier developers is behavior, and I’d recommend you start with SharePoint Designer 2010 Workflows (and maybe even SharePoint Designer 2007 Workflows. They are very different in their approach and both are applicable). If you plan to keep working on SP2010, I would then look at Introducing SharePoint Visual Studio Workflows, but keep in mind that this knowledge is deprecated (meaning it’s going away, not gone) in SP2013.

If you want some light reading in between, you can look to the “Explained” issues to see practical examples of SharePoint development. These are SPCurrentUsers Explained (beginner to immediate), SPTags Explained (advanced), as well as SPThemes and SPSampleData Explained (intermediate).

The full recommendation here is for 11 issues,which makes it a perfect candidate for a 13-issue bundle ($149.50). That way, you’ll have a couple of issues to spare for other stuff, for example the upcoming Advanced Web Part Development, Professional SharePoint Development, or Introducing SharePoint 2013.


PS: Oh, and in case nobody knows, I’m the author of these journals, so I’m very much affiliated with them 🙂

Pin It

SharePoint 2013: As Light as a Feather

OK, look, the end of the world predictions need to stop. Yes, I’m talking about the memory requirements for SharePoint 2013. No, you’re not going to die from starvation, having been unable to afford the upgrade.

You may recall that I broke my self-imposed radio silence regarding SharePoint 2013 a few days after the release to correct what was rubbish information from several MVPs (and others, and I would like to stress, not all MVPs are idiots).

I’m going to break radio silence once again regarding this topic because it seems the community is going nuts over what is essentially very light requirements. In fact, I’ll claim, and show you, that SharePoint 2013 is really light as a feather.

What? You’re Nuts! 24 GB Is Way Too Much!

OK, OK, let’s start with the facts. SharePoint Server 2013, according to the current documentation, states that a minimum requirement for development is 24 GB RAM. There are other Microsoft documents suggesting the same. Those are the numbers, so let’s examine what this means.

Let’s start with some history. In 2009, I reported that SharePoint 2010 would require a minimum of 8 GB RAM, or about 4 GB for a development setup. I predicted that most people would want 4x that, and lo’ and behold, most people today use either 8 or 16 GB of RAM for their development machines.

What’s interesting about this, beyond the fact that I was right and everyone else was wrong, is what people had to pay for that RAM. In 2009, and I’ll compare the first memory price update after the public beta in November, the price of a MB or RAM (MB, not GB) was $0.0205, which roughly translates to $335 for 16 GB. (source:

Note: I’ve previously stated that I had to pay $800 for my 16 GB back then, but I obviously didn’t shop around enough.

Today, on NewEgg, the cheapest 32 GB laptop RAM goes for $172 or roughly half the price of what the required RAM for 2010 cost in 2009. In fact, this comparison isn’t even accurate, because the first price, from 2009, is for the cheapest RAM possible, which was 2×4 GB DIMM. The cheapest 2×4 GB DIMM you can get from NewEgg today (August 1, 2012) is $38.49, which translates to a price for 32 GB of $153.

The point of this, however, is to say that what you have to pay for a reasonable amount of RAM for SharePoint development, is less than half of what you had to pay back in 2009. That’s right, the ridiculously over-the-top requirements actually cost you far less than what we had to pay if we wanted to do reasonable SharePoint 2010 development.

It’s Still Too Heavy!

One of the arguments I made earlier was that the early ejaculation MVPs should have known that adding a ton of bricks to your wagon will mean you need to add more power to pull that wagon at the same speed.

If you look at the improvements and the massive amounts of new features that SharePoint 2013 adds on top of SharePoint 2010, it’s no wonder that you need more hardware. Does anyone still really think that new software should just run fine on three year old hardware?

The amazing thing, however, is that everyone seems to focus on having to shell out a couple of hundred bucks, rather than the fact that, with SharePoint 2013, you actually get twice as much functionality at half the price!

Geez, I don’t get some people and why it’s so difficult to understand that professional performers need tools that are up to the task, especially in a business that pays as well as SharePoint does.

I Can’t Get Approval For It!

I’ve been asked several times about how to approach managers and business people to get approval for such a ridiculous amount of money. I’m going out on a limb here and guessing that those asking haven’t done their leg work in figuring out how much it actually will cost, but just assume it’s going to be expensive. That’s not the case.

However, there are some who are nervous because they might need a new laptop, and after all, a 32 GB beast with four cores will ruin any budget, right?

You’re wrong.

I’ve checked with a couple of vendors. Dell currently has a ‘beast’ in its Precision M6600, which goes for, with no RAM and just a quad core upgrade, for around $1800. That gives you a 17 inch laptop with room for three hard drives. It’s extremely powerful, I’ve had its older brother for over two years now and it really packs a punch. Add 32 GB NewEgg RAM to that and you’re down a whooping $2,000 for one of the most powerful laptops you can build today.

A smaller size HP EliteBook seems to be around $1,400 ($1,600 with RAM upgrade). A Lenovo W530 is around $1,300 ($1,500 with 32 GB RAM).

I Still Want To Run on Less!

Here’s the thing; it doesn’t make sense to save a couple of hundred (or at worst, a couple of thousand) dollars by using inferior hardware. Let’s say you’re a SharePoint consultant working for $150 per hour. If your productivity drops even 10% because you have problems with performance, then you incur costs of $15 every hour you work. After 10 hours, you have lost more money than a RAM upgrade to 32 GB would cost. After 100 hours (which is just over two weeks) you have lost more money than a new laptop would cost.

So, stop turning your dime over and over again, and get out there and buy the tools you need to do your job. If your boss says otherwise, tell him he or she is an idiot that is costing the company money every moment he or she delays approving your upgrade.

And, let’s face it, it’s cool to have the biggest laptop there is, isn’t it?


Pin It