LightSwitch... Or Not.

As Microsoft often does, it took a great tool in LightSwitch, which had gained a pretty hard-core following of power users, citizen developers, business analysts, and even some seasoned developers, and completely threw it into the ditch, without any further, substantive explanation, just like it did for Silverlight.

How do we know this change is permanent?

1) They made no (I repeat, NO!) improvements to LightSwitch in the Visual Studio 2015 release candidate. It's a small wonder they included it at all.

2) Andy Kung left Microsoft.

3) Beth Massi (or whatever her married name is now) is also no longer doing LightSwitch content.

4) Jay Schmelzer so eloquently danced around the topic better than any Democrat politician could ever do when it was brought up during a podcast. Pertinent comments start around the 5:00 mark in the podcast.

So... what's next? I wrote previously that learning skills like JavaScript, JQuery, and CSS would be vital for survival in the SharePoint world. This assertion still resounds true today.  Another stack that I have just recently started learning is asp.net MVC, used in conjunction with Entity Framework. This development toolset, like LightSwitch (though in a much different way than LightSwitch), handles much of the data source connectivity for you and it JUST... WORKS. You can still work with fully relational datasets, created either by code-first or by scaffolding via Entity Framework. Code can be generated for you while still customizing the business logic, but you will still need to know HTML. HTML helpers and RAZOR syntax help shorten the code required to render the output.

Microsoft Virtual Academy has some great resources on MVC and Entity Framework featuring Christopher Harrison. Just search for MVC and Entity Framework.

The biggest disadvantage is the difficulty of implementing file / database relationships, which was very easy in LightSwitch, though "Mike" shows how to do both database and file system storage and relationships here. Interaction with SharePoint lists and libraries is exclusively through javascript and is still tedious enough that I wouldn't recommend it in good conscience to non-developers.

Takeaway for today - LightSwitch isn't dead, but it's future looks grim at best and appears to be marked for deletion. I suspect the same will occur with Access 2013 Web Apps. If you're trying to do anything with some Microsoft tool that isn't part of the .net core stack, don't count on it being there in two years.

You Don't Have to Be a Weatherman To Know Which Way the Wind Blows.

Which direction is the wind blowing in terms of SharePoint?

Answer: JavaScript/JQuery (read "function") and CSS (Cascading Style Sheets, read "look and feel"), if you want to do anything above and beyond out-of-the-box with SharePoint 2010 and 2013.

With every new release of SharePoint, Microsoft is allowing SharePoint to be more flexible, but at the cost of becoming less user-friendly for non-developers. The newest release of SharePoint, SharePoint 2013, makes heavier use of "apps" that can be customized through script.

SharePoint Designer 2013 has taken away its Design view, and thrown the form customizations over the fence to InfoPath 2013.  InfoPath 2013 has some limitations, and so the most effective way to change the function of your SharePoint sites is to use JavaScript and JQuery. This means that even a Site Collection Administrator would be well-served to have knowledge of JavaScript, JQuery, and CSS.

Fortunately, there are many good books available on both subjects, and even books focused on using JavaScript, JQuery, and CSS within the context of SharePoint 2013. I would highly recommend also getting a book on the use of InfoPath 2013 and even Office 365, Microsoft's cloud-hosted SharePoint solution.

For an all-in-one book, I recommend "Pro SharePoint 2013 Branding and Responsive Web Development". "JavaScript and JQuery: The Missing Manual" is also a good read if you're starting anew with any type of development/programming and has good cross-references within.

Best of luck, and happy coding!

The Problem with ITIL

ITIL (Information Technology Infrastructure Library), as defined on WikiPedia, is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business. ITIL also aims to create accountability within IT organizations. Sounds all fine and dandy, right?

Well, my experience with ITIL so far has put some problems in place that are nearly impossible to overcome, especially in a SharePoint environment... and I do mean PROBLEMS.

1. ITIL creates needlessly BLOATED IT organizations. There is a job description for nearly every role in the ITIL structure, and many companies and government enterprises feel the need to put a warm body in every seat defined by ITIL, just in the name of being ITIL-compliant, whether that warm body is genuinely needed by an organization or not.

2. ITIL draws lines between organizations that should be working side-by-side with each other and sharing certain responsibilities. Often times developers and systems administrators have both skillsets and responsibilities that overlap.  The strict demarcation that an ITIL-compliant enterprise places between developers and sysadmins can reduce teamwork and collaboration between the two, and worse yet, an atrophying of the skillset that the other possesses. Another unforeseen side effect is that SharePoint Administrators get divided into different levels, leading to expertise in one layer or another of the SharePoint administration hierarchy, but with this focus comes lack of use and loss of familiarity with the the layers above what that administrator has access to (ie. someone whose level of access only goes as high as the Web App or Site Collection).

And worst of all (and a problem my current organization is facing),

3. An team that controls one component of a SharePoint implementation can completely de-rail progress made by the other teams. For instance, the team that is responsible for physical or virtual servers chooses to not upgrade a server whose upgrade is needed to go to the next version of SharePoint... whether that be Windows Server versions or SQL Server versions. All it takes is ONE of the teams not cooperating and poo-pooing the progress of the others by saying "no, we're not going to do that" to bring mission-critical initiatives to a grinding halt. And no one holds the offending group accountable, which defeats the accountability portion of the primary goals of ITIL.

4. Virtualization snapshots are NOT a Disaster Recovery (DR) solution for SharePoint and Microsoft Premier Support does not support SharePoint farms that have been rolled back on VM's! Try telling this fact to the shop that controls all of the enterprise servers... 'Nuff said.

Many companies and government IT organizations are requiring ITIL certification for their administrators,developers, managers, and support personnel, and I think it is somewhat wise to be knowledgable about the intent of ITIL, but most take the concepts too far.

So, to those apologists and die-hards that think ITIL is absolutely the greatest thing, please please PLEASE make sure that you're implementing it in a way that avoids the pitfalls I've listed above.

Definitions #1: SharePoint Developer

Today, I would like to define for you what a SharePoint Developer does. Simply stated, a SharePoint developer performs actions that involve writing code to meet custom needs of the enterprise. These actions extend the capabilities of SharePoint above and beyond what can be done out-of-the-box, with InfoPath, or with SharePoint Designer. Within the realm of browser-based applications, there are two ways to present interactivity between the user and the web in which he or she is interacting: Client-Side and Server-Side.

Some developers specialize in one or the other, but can do both. This is dependent upon several variables, such as business requirements, developer skillset, and access levels.

Client-Side development is handled at the browser level, meaning that most of this kind of work is done with HTML or javascript, and can involve technologies like JQuery, JCarousel, etc. For the most part, this can be done with only Site Owner or Site Collection Administrator permissions, or in some limited cases, contributor. Some of the tools required for this include SharePoint Designer, though some of the work can be done in a simple Content Editor Web Part and a library to store any resource files, such as JQuery. A client-side developer may also opt to take advantage of tools present in Microsoft InfoPath.

Server-Side development is handled, as the name suggests, at the server level. For these scenarios, the developer will need a solid foundation of .Net experience, as well as a solid understanding of SharePoint architecture, queries, workflows, and the SharePoint Object Model. Tools that the Server-Side developer requires include a development SharePoint environment (read farm, even if only a single server instance) for which he or she has administrative access to, as well as Microsoft Visual Studio, to develop, package, and deploy what are known as features. These individuals can have some experience (or at least some know-how) as a SharePoint administrator, but it isn't necessarily required.

Other duties that are typically required by developers include knowledge of version management, configuration management, and most importantly, the ability to compile quality documentation of their work.

The Important Recruiting Take-away: Many developers are knowledgable on both, but you, as the recruiter, need to know what you're hiring for and what that person will have access to at their job place. You do NOT want to place a candidate that only has client side experience for a job requiring Server-Side skills, or, on the other side of the coin, a person who has and wants to utilize server-side skills but will only have access to implement client-side methods when they arrive at their new job site. 

1. Make sure that the hiring manager has given you, the recruiter, an accurate job description for any development positions.

2. Take a close look at the resumes of your candidates. Do they possess use of Visual Studio in the context of a SharePoint environment? In my case, I did a brief stint as a .net developer long before I gained any experience with SharePoint. If a recruiter examines my resume, they will see that I have no .net experience during the jobs that I have used SharePoint. I also have in bold letters towards the top of my resume that I am only interested in SharePoint Administrator positions only... but somehow I still get reqs for SharePoint developer positions... to which I immediately delete, knowing that my current resume wasn't even opened by the recruiter.

3. An extra five minutes of looking at your resumes will yield you 5-10 times better candidate proposals to your hiring managers. The hiring managers employ you to present qualified candidates and to separate out the wheat from the chaffe so they don't have to. Read the resumes!