top of page
Search
  • Writer's pictureMaarten Boonen

Clarity around the magical world of development

Updated: Aug 10, 2020


Big words

The word development has a different meaning depending to who you talk to. We can make it sound like rocket science as we’re going on a mission to Mars but in the real world all of us are developing, methods, templates, workflows, some weight on the belly or complete automated solutions.

Why do we do this? Because we notice it helps us do things the same way over and over or speed-up the work, it gives us structure and support.

The Developer

Some times our friendly sales guy or recruiter contacts us in search for a developer but what needs to be developed? The two main different developer types are the industrial developer and the software developer.

In industrial development the solution will be programmed in a chip or circuit board to do certain things. For a software developer we use different development languages and build a stand-alone application or add-in to solve an issue. As we know a lot of development tasks can be done from a user interface and others needed to be written by code.

A software scripter who’s developing scripts to automate things can be an ace in Powershell or Visual Basic but can know nothing about C# or Java. Basically the tasks are so different it are complete different professions. Similar for a SharePoint front-end developer whose focus is on the user experience and the user interface and a SharePoint developer who builds C# WSP solution packages or Apps with C# or Angular JS code. Yes there are über developers among us who know lots of types of development and languages but the key here is to differentiate them.

Let’s shed some lights on the subject

Not everything is easy of course but just to spread some high level granularity on the subject I always like to divide some development tasks in categories which are easier to understand if it’s hard or can be done by end-users.

Since most of us managed to get through kinder garden we are familiar with this awesome disco light concept we use in daily situations on the road, “the traffic light”!

Green

By my opinion it’s everything we can do with the Out-Of-The-Box features provided to the end-users in SharePoint or Office.

  • Creating List, Libraries with extra columns

  • Calculated columns

  • Forms with InfoPath or Nintex

  • Office Templates with smart parts

  • Out-Of-The-Box workflows

  • Dashboards, with Excel Services, SharePoint, PerformancePoint, Power BI, Visio

  • Conditional formatting

  • Content Types

  • And many more

Orange

Orange and green development have a big overlap. A lot can be done by an end-user but it needs a high level of conceptual and technical thinking it can have some risks if you’re modifying things you should not. That’s why the Orange level of development can be done by a so called PowerUser, Business analyst or a Consultant.

  • Custom workflows, SharePoint Designer or Nintex workflow

  • Modifying and adding simple JavaScript’s, JSlink or Display Templates

  • Integration of information from other Line-Of-Business systems

  • Branding User Interface

  • Templates with business logic

  • Dashboards which combine information from different sources

  • Many more

Red

When we speak about red development the flags need to go up and we need to realize some things first before we agree to go on. When we talk about Red development I mean Code, C#, C++, Angler JS, JSON, etc. Basically the deliverable will be a package, authentication providers, event receiver, web service or something like this.

The question will be regarding compatibility, modifications, dependencies, is it portable to other farms. Do we own the source code, do we have proper documentation, what is proper documentation? etc. Make sure that the deliverable will be one package per functionality and not 20 functions in one package. If you have one package it will be harder to modify and more parts of your farm are affected.

Another thing we need to realize is if we can do it with orange development and why we should not. Depending on, if you ask a true developer he will think from a code perspective and do things with an event receiver what can be done with a workflow which would be the consult way to go. Of course there are more ways to go to Rome but it should not always be done like that and certainly not based from an hourly rate perspective.

Don’t use code or OTTB features because you can but because you know it’s the best method.

38 views
bottom of page