SharePoint Designer 2013 Design View: It’s not a developer vs non-developer argument

Having read a few of the posts around and the comments to said posts as well as on forums, I can’t help but feel this discussion is taking on a “developer vs non-developer” view. From the developers standpoint you have the opinions like that of Bjorn’s who think that past atrocities perpetrated by power users that are sufficient reason to take away the core of their power… design view. Common arguments for the power users, such as those posed by Marc, range from the increased barrier to entry for non-developer types (the task of debugging XSL has been made extremely difficult for developers meaning its virtually impossible for non-developers) to the inflated budgetary requirements (due to the need for more developers).

The problem I take with these arguments is that they concentrate on this whole “developer vs non-developer” argument. To be perfectly honest, on this playing field the developers have it. The rubbish solutions that the deign view has helped contribute to is a pretty solid reason to remove it as developers are the ones that should be doing any kind of development. Although I do agree with this sentiment, my argument exists on a different field. The argument I make is one of negotiation. Of course this argument only works if you are an ethical consultant not looking to take your client’s to the cleaners. I’m actually a massive optimist in the human spirit so for the purposes of this post I’m going to assume you too are not looking to rip off your client.

For my consultancy (Seven Sigma Business Solutions but soon to be Inovus), governance is at the forefront of everything we do. A huge part of this is training of power and end users. In our consultancy the argument of “rubbish solutions” is really a null argument as we will setup a simple development environment (a development site collection typically) in which the power users first create their SharePoint Designer based solutions. This gives them a chance to learn but also provides us with a way to govern their solutions before they have a chance to go into production thus providing some level of quality control.

This learning process is extremely important to delivering good solutions because ultimately the users are the ones that understand their business the best. One of the toughest challenges I have faced as a consultant is the whole “the customer is always right” mentality. Whilst correct, the meaning has been sorely manipulated. The customer is only always right if they have all the right information and often they are very poorly informed or are sorely misguided. Once they see the limitations of SharePoint with their own eyes and understand the difficulties, it means we can then proceed to negotiate for the best solution. This solution often not only requires configuration/development of SharePoint but also cultural/process change within the organisation itself. To put it simply, Microsoft has now removed the greatest learning tool I had for helping non-development users grasp the complexities involved with developing innovative, user-targeted solutions in SharePoint. By removing this learning tool all developers are going to suffer as they now have one less weapon in their belts that they can negotiate with.

6 thoughts on “SharePoint Designer 2013 Design View: It’s not a developer vs non-developer argument

  1. Chris:

    This is a well thought out and valuable post. You and I actually agree to a large degree.

    The reason I raise the “hire more developers” conclusion isn’t because I see it as a developer vs. non-developer thing, it’s because I’m trying to figure out how to advise my clients and others who follow me. There’s a lot of good work that’s been done out there with SharePoint Designer and we’ll lose the capability to maintain it in moving to SharePoint 2013 without more developer help.

    In my ideal scenario, IT becomes an benificent empowerer of citizen developers. For every instance where a citizen developer has wreaked havoc with SharePoint Designer, I’d argue that there are maybe dozens of instances where good work has solved real business requirements. In the case where something bad happens, it’s frequently the case that IT has turned a blind eye to the citizen developers, even saying “Do this at you’re own peril!” If IT were to assist and inform those same citizen developers when they need it, I posit that the majority of the calamities could be avoided.

    BTW, while I’ve heard a few calamitous stories (all solvable and usually driven by poor permission planning or insufficient disaster recovery processes), most of the rhetoric seems to focus on what those citizen developers MIGHT do if they were to dabble with SharePoint Designer.

    One thing we all seem to agree on: removing the Design View is an odd decision on Microsoft’s part.


    • Hi Marc,

      Actually I totally agree with your post and I suppose I forgot to say that explicitly in this post.

      What prompted me to write this post was some of the comments made by others on your post as well as a few other posts, forum comments, and tweets out there. What I noticed was that any discussion kind of devolved into a “developer vs non-developer” argument. I noticed how you felt the need to “defend” your developer status in your post which I think is a result of an elitest developer attitude out there.

      Having seen all the comments and debates, I just felt the need to name the fact that these discussions were going off track and to remain focussed on the issue at hand. You make an important point and we don’t actually have any figures on how many bad deployments there have been versus good deployments. All we have is a lot of hearsay from the community and you will always hear about the negatives more than you here about the positives.

      My hope (and this is purely an opinion based off no evidence) is that Microsoft will eventually bring back the Design View. My greatest hope is that the decision taken is actually one based more in the cost and difficulty of re-developing the engine underneath it all rather than a conscious strategic decision to de-claw power users.

      Chris T.

  2. Marc, your point about “might” is spot on and I can understand why Chris picked up on it re his note on heresay. Chris and I have had to do the remediation thing together many times and he would absolutely agree with me that the vast majority of ‘attrocities’ we have seen committed (and have had to disentangle) have actually come from packaged up solutions that make the whole install brittle (and on that note, your rationale presented in your 3 tier whitepaper is pretty much how we see it too).

  3. Chris,

    I’m fully aware that the debate is about more than devs versus non-devs.

    I’m a proponent of the fact that if you are developing, you are a developer, regardless of whether you are using SharePoint Designer, the web interface, or Visual Studio. As such, it’s actually not about developers versus non-developers, it is about sucky, lazy “I don’t want to learn anything more than I have to” developers versus “I’ve walked the miles it requires to know how to safely and securely develop”.

    My argument is closer to yours than you seem to think here, namely that it is a question of training versus no-training. The ease of access and the low barrier of entry for SharePoint development in the first and middle tiers make it seem that you don’t need the training.

    This has been Microsoft’s curse for close to 20 years; they market themselves by showing how easy computers are, that you can just sit down in front of Windows and start working. The result is a set of users that think they don’t need to think in order to use computers. It has taken almost 20 years since the release of the epitomy of this attitude, Windows 95, and we’re still not even close to giving users an environment that is safe and secure to use without extensive training. We still think we need anti-virus and personal firewalls, which are themselves the ultimate blinders for the dangers that are out there. However, rather than train our users in what these dangers are, which would mean they would be safe and secure long-term, we keep selling them yet more software that they have no idea how works. We never want to solve the problem, because we can sell them a solution that makes it seem like there is no problem.

    So, your solution goes something like this, in the world of security; give the users a ‘personal’ firewall and ask them to set it up, and after attempting to set up a firewall to provide any kind of real security, they realize they are completely incapable og doing so, sell them on the idea that you actually need to know how security works before you can complete the task safely and securely.

    I agree with this approach only because the idea of ‘personal firewall’ exists, but I think that existence is the core problem that we need to address. A personal firewall provides no security what so ever unless you know quite a lot about why you need it or don’t (and it’s far more often the latter). One of my best friends, being in posession of more security training and certifications than you can fit in a downloadable resume, say it like this: Put up a firewall, learn why it’s there and what it does, and then you take it down because at that time, you know why you don’t need it.

    In SharePoint Designer terms, the ease of access is the core problem; users have been lulled into a sense of capability, which is great if you’re trying to build someone’s confidence, but not so great if you’re trying to build a business. This, my friends advice would be something like: Put up SharePoint Designer, learn what it does and why it’s there, and then take it down. The main difference is that SharePoint Designer is actually quite useful outside just the ‘look ma, I can ride a critical business solution, no hands!’


  4. Chris: I’ve written things like a keyboard handler for DOS in Assembler (MASM!), burned code into EPROM chips, and programmed POS devices with REXX. I know I’m a real developer, regardless what language it is. Sometimes I get cranky about those “real” developer comments. When Powershell hit the streets, I was hoping that the “script isn’t code” nonsense would go away, but alas…

    Paul: Now the challenge is how we can enable that middle layer (tier, strata, laminate, whatever) of development given changes in SharePoint 2013. Rather than focusing on the problem anymore, at this point I want to try to figure out good suggestions for people so that they can carry on the good work.


  5. Chris,

    I used to call the development environment you describe as “a sandbox”, but that gets easily confused with other Microsoft terminology.

    SharePoint is about empowering users and giving them a sandbox to play in limits the damage that can be done and encourages learning by failing without the consequences. Eventually, everyone needs to learn even more by failing with consequences, but it’s nice to have that wide open play space.

    I agree that losing SharePoint Designer design view removes a training and learning tool. I also agree with Marc that we all need to determine how to advice others now that we have this limitation and other new alternatives. Personally, I’m looking to the App Model and tools like Napa at the moment.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s