Why Dynamic Typing in SharePoint is Suicide

I was browsing through Glyma today and noticed a comment on my own blog that requires some… explanation. As usual, the poster is an idiot, or at least makes an idiotic comment, but before we get there, a few things need clarification.


Yeah, you see, there’s this guy, Paul Culmsee, who is beyond awesome. He’s the guy that got me started writing and now, 20+ books later, I still find myself wondering if I’ll ever compare to Paul’s writing. 

In any case, his company has come out with this brand new thing called Glyma which I guess is a tool for mind mapping or dialogue mapping or whatever it is called. I don’t know too much about these things or its terminology, but I know one thing: It’s frigging awesome!

What it does is basically create a tree of knowledge (and no, you religious nutcases, not that kind of tree of knowledge) where you can refine information and knowledge down to its minute detail. I find myself browsing through the trees already created to explore ideas, review content, and most of all, laugh at some of the knowledge. And no, that’s not always the good kind of laughter either.

I’ll most likely come back to Glyma in far more detail, but for now, I want to point out one particular topic.

Note: You can check out Glyma yourself at http://www.glyma.co/. But don’t do it right now or you’ll never come back here to hear how to save yourself from embarrassment in a discussion on dynamic typing in SharePoint.

The topic in question is on how awesome SharePoint 2013 must be because it uses all the cool features of .NET 4.0 such as dynamic typing.

Dynamic Typing?

You may not know the innards of programming, but basically, there’s a somewhat religious debate regarding a topic called typing, of which there are two types, pun intended: static/strong and dynamic/weak.

Certain languages are dynamically typed by default, such as JavaScript, Perl, and to some extent and very optional, C#.

The difference may seem subtle but is very important in building stable systems. This fact seems to elude proponents of dynamic typing.

Essentially a statically typed language will make sure before you can even complete writing a piece of code that any properties or fields exist. A dynamic language couldn’t care less.

For example, let’s say you have an invoicing application in SharePoint with an item called Invoice that has a field called DueDate.

In a statically typed language, you cannot complete the writing of code if you mistype DueDate (for example if you write Duedate or dueDate) or if you write DueDate but the field does not exist. So, in a statically typed language it is impossible to misspell field names because your code will simply not run.

In a dynamically typed language, however, you have no idea whether the field exist when you write the code. If you misspell something, you won’t find out until your code breaks, which can happen at any point from now and until the sun blows up.

SharePoint in Particular

The particular comment in question is to my post on how SharePoint 2013 Apps Solve Non-Problems Only, readily available from your local search engine. The comment points out that only the .NET 4.0 runtime, which is available only in SharePoint 2013, supports dynamic typing and that users that want to target older SharePoint version misses out on that awesomeness.

[…]the dynamic keyword (dynamic would have been awesome in dealing with list item columns, a little puppy dies every time someone codes item["ColumnName"].ToString()). Always felt stuck in the past doing SharePoint 2010 development.

SharePoint encourages users to change their data so you may think that dynamic typing is an awesome idea. After all, what if you want to change your field names around? You may think that Duedate just looks better than DueDate so being dynamic must be great, right?


You see, dynamic typing, which is the stuff offered by the dynamic keyword, doesn’t actually change the code. It just ignores checking to see if you’ve written it correctly. If the user changes the field name from DueDate to Duedate, the code will still run; it will just fail or cause unwanted effects. You may not notice that because, you know, your developers ignore such mistakes on purpose because they’re lazy. Or stupid. Or Both.

I’m Not Lazy! Static Typing is Just As Bad!

Static typing won’t save you from users changing the names of fields. It won’t even save you, really, from misspelling of names. Like the commenter pointed out, it’s possible to write stuff like item[“Duedate”].ToString() (which turns the value of the field named Duedate into a piece of text). That’s because the “Duedate” part isn’t strongly typed.

That’s why you don’t rely on dynamic typing at all. Only an obtuse idiot or complete newbie would write item[“Duedate”] because if someone changes the field name, and that is supposed to happen, the code breaks, just like if you use the fancy new .NET 4.0 features and type item.Duedate instead.

The latter is just as bad, at least in SharePoint. It kinda works in other frameworks where field or property names aren’t changed, though. It’s still lazy.

Instead, real developers with proper understanding of problems such as this knows that you  rely on fixed or static properties of fields if there is a chance that non-fixed properties can change. Nothing dynamic. Fixed is reliable, stable, and dependable. Dynamic is not. Dynamic is lazy and unstable and takes away your freedom to change your field names.

Luckily, the Microsoft developers are usually good developers and know about simple problems like this. They have, completely free of charge, given you several fixed and static properties with which you can work as a developer. The InternalName property is my favorite and regardless of what the user does with regards to changing the display name of a field, the InternalName does not change. From the InternalName you can find the dynamic name reliably, but you can’t do it the other way around.

The point is that the dynamic keyword in .NET 4.0 isn’t useful in SharePoint at all. You still need to do exactly the same thing in .NET 4.0 as in .NET 2.0 to ensure your code is stable and reliable because, you know, SharePoint is quite independent of such things as fancy syntactic sugar or lazy developers.

Note: With the influx of newbie JavaScript developers and conversion of possibly decent SharePoint developers to SharePoint 2013 App JavaScript nutjobs, I’m expecting a ton of Item.DueDate code in the future because, you know, it’s more important to hang with the cool kids than to understand your job.

This, by the way, is somewhat of the same problem with content types. Newbie developers will reference content types by their names for example if they want to add columns to the Item content type. You can see this if you ever see SharePoint code anywhere that looks like ContentTypes[“Item”].FieldLinks….

If that’s the case, and you see such code in what your developer hands you, take that developer out back and beat them over the head until they can tell you why that is a stupid idea (and I’ve been beat over the head enough that you don’t have to point out that I’ve done this error in the past).


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

4 Reasons why SharePoint is Dying

I’m afraid it has come to this. SharePoint is dying. It used to be a great platform with awesome promise but somehow, it’s now starting to put its affairs in order and preparing for the inevitable end.

I’m here to tell you why, and sadly that there’s nothing you or I can do about it. It’s time to pack up your stuff and move on because the last final gasps of air are about to happen and that’s rarely a nice experience.

1. The App Model

So, let’s kick it off with the App model. Never really made it, for some very obvious reasons.

I recently saw a video with Scott Hanselman where he was taught that now everyone who knows anything about web development is also a SharePoint developer because SharePoint is now just a provider of data accessible through OData, REST, and all those other fancy buzzwords.

But tell me, why would you want to start developing for SharePoint if all you need is a data store? I mean, if SAP came out and said “Sure, we have REST APIs now” would you stop what you’re doing and run over there?

Of course you wouldn’t! And neither would any PHP or HTML developer want to develop on SharePoint. There simply isn’t any point in using SharePoint for them; they already have far superior frameworks and platforms for storing data. Even Microsoft own services like Azure are far superior to anything SharePoint can offer as a pure data store.

Microsoft seems to think that because you can now send JavaScript requests to SharePoint, every JavaScript developer is now a SharePoint developer, which is roughly the same as saying that because Word supports writing, everyone who ever learned to write is a Word user.

If you want to appeal to someone, you need to offer them something better than what they currently have. SharePoint, as a backend, isn’t that, to anyone. Not even to existing SharePoint users.

The App model has failed and it took a lot of the development story of SharePoint with it.

2. Jeff Teper Left

I’m sure you have all heard the news by now, but Jeff Teper, my new superhero in Redmond, has been reassigned. I’m sure it’s a coincidence that his move happens literally months after I publicly declared by admiration of his new attitude.

There’s a reason, though, that Jeff was fired (or promoted, which in corporate America is much the same thing).

Jeff made SharePoint. He was there from the very beginning and stuck with it until the bitter end. Nobody knows SharePoint better than him. He orchestrated everything, including the recent push for the online thing they do these days.

I think Jeff was too focused on SharePoint as opposed to hanging with the cool kids. Think about it. It doesn’t make sense to fire or ‘promote’ someone who has massive success in what they do. If the recent shift in SharePoint was the success that Microsoft wants us to think, why wouldn’t the guy that made that happen still be around?

Some things that Jeff has said has left me to believe he wasn’t as convinced about the Office365 thing as the community herd is. I may be just overly sensitive to these things, but I suspect Jeff left because he doesn’t think there’s the same future in SharePoint anymore.

3. Lack of Innovation

SharePoint 2013 is a huge yawn.  Really.

Sure, there are plenty of bells and whistles, but after you’ve seen through the makeup, it lacks any innovation that would make it last for another ten years.

There still isn’t anything in SharePoint 2013 that I cannot accomplish in SharePoint 2007. Every thing that’s hailed as innovation is really just moving a few pieces of furniture around and claim that you have a new house.

Sure, there’s the App model, which isn’t particularly innovative considering it’s just going back to putting HTML pages somewhere and sending JavaScript requests to a web service. That stopped being innovative around the turn of the century.

There are a few new apps (not Apps) that ship out of the box, but nothing that would warrant the massive investment it would be for a customer of any size to upgrade. Most of the other innovation happens on other platforms like Office365 and Yammer.

SharePoint 2013 is just a slower version of SharePoint 2010 and the other differences are mostly cosmetic. Gone are the days when you had innovation like web parts, or workflow, or content types, or the solution framework, or delegate controls, or the event engine. These features made and make SharePoint unique, but guess what; they all happened almost 10 years ago.

4. Too Slow but Too Fast

In a twist of irony, Microsoft’s release strategy is both too slow and too fast.

Microsoft has decided to release a new version of SharePoint at around the same release cycle they’ve had until now, meaning a new major release around every three years. We’re all holding our breaths for SharePoint 2016.

That’s not quick enough for Microsoft to stay up-to-date with the latest and greatest that they seem to want to do. It’s not fast enough to hang with the cool kids. By the time you get those new pumps, they are already out of fashion and everyone uses moon boots, and by the time you’ve nagged enough to get your parents to buy some genuine Tecnicas, everyone uses sneakers.

On the flip side, however, your parents, who pay the bills, think the changing trends you try to uphold are changing way to fast. They don’t have time to catch up. You may think they’re awfully old fashioned, but they do pay the bills and they would like to make sure they get some value from the shoes they buy.

Similarly, organizations do not care about what the latest and greatest is. They have been burned, like your parents, on investing in the latest and greatest just a few years ago on the promise that this would be the investments they would truly have for decades to come.

To you, the speed of evolution may feel too slow because you can’t have the latest and greatest all the time. To those that pay the bills, the pace of change is too fast to yield any reasonable value. Microsoft is too slow to adopt new changes in technology but too fast to get their customers to invest in long term solutions.

What Can We Do?

Sadly, with the state of affairs, there really isn’t anything you or I can do, not even as a community. We’ve been forced or at least highly encouraged to move away from the tried and true methods of development; we’ve lost the guy that made SharePoint everything it is; we’ve been left without major innovation so that instead we can get a mediocre data service…

The only thing we, as a community can do, is stop listening to idiots. Stop listening to those that promises us what a great future InfoPath has; how awful it is to use managed code; how everything will happen in the cloud.

The only glimmer of hope came from something Jeff Teper said a couple of months ago (my emphasis).

We’ll listen, learn and adapt to customers, partners and what is going on the market for the scope and timing of the next release but if you asked us today, we’d expect our general approach (cloud first/best, solid server upgrade) would stay consistent change in that timeframe.”

Perhaps that listening can turn out to be important, even  though Jeff is now gone. Perhaps we, as a community, can tell Microsoft that we want SharePoint’s strengths rather than another competitor to hosted MySQL, Amazon RDS, or SQL Azure.

Or maybe it’s just my opinion… What do you think?


Pin It