Lately, I have been approached by recruiters for projects labeled SharePoint developer. While this sounds intriguing, I am very wary about taking on projects with the ” Proficient in being able to extend and customize SharePoint Online
• Expertise in all the OOB SPO features
• Proficient in .NET web site development (C# and ASP.NET)”
I get it. There are environments where custom and out of box applications exist. I however, do not support or condone custom applications.
Throughout my SharePoint consulting life, I have seen my share of creative and sometimes very ugly SharePoint sites. Those sites and applications are often riddled with custom code that have run it’s course and now sitting idle and festering on the SharePoint platform. Yes, festering. As you can read, I am not a fan of custom code.
My motto is, just because you can, doesn’t mean you should.
As a SharePoint consultant, I am often brought in to patch up and repair broken sites, reverse engineer and often replace broken forms, and perhaps consult and advise on better ways of working SharePoint. Better ways of working smarter.
What I am talking about is having a coming to Jesus talk with the client and coming up with a plan to move forward from broken sites and applications.
Often what I see are sites and forms that have been altered because 1, the previous consultant was a developer who came up with a quick and dirty solution to get the job done and 2, did not understand what the client’s needs were.
Questions that I ask when consulting are.
What are you using the site or form for?
How are you currently using the form or site?
Where are you now in your current work state?
When you are the 3 basic what, how and where, you get a good understanding on what their business model is about and how to approach the project/issue/bug. You can come up with a working solution that is simple and clean.
Simple, meaning that the solution is perhaps out of box rather than custom code that only the developer knows how to fix and clean, meaning it can be modified for future edits or upgrades.
I am not saying that custom code does not have a place in the world. There are many beautiful sites and applications all done in the custom realm. I don’t hate custom code developers. Some of them I have partied with. I find them brilliant and fun to be around.
However, as a SharePoint consultant, I often end up having to clean up a lot of broken things that often occur because of failures and upgrades.
I recall working at biotech research company a few years ago where I was brought in as a SharePoint consultant. It was early in my career and I had already jumped on board as an out of box consultant. I knew my way around InfoPath and was quite fond of the simplicity of the usage.
The IT department had a reputation of being the Wild West as far as projects were concerned. Internal clients would request projects that were often costly and hard to maintain. They got what they wanted because they were the money makers of the company.
I worked with a C# developer who firmly believed his code was far superior and could out perform any solution. I had my reservations on this approach as I knew it meant dependencies on the developer. Basically, the developer had worked himself a nice position. A project came up on the table where the end user needed an intake form to allow continuous updates and used by different teams with different roles.
I came up with a basic InfoPath form using the multiple row updates and roles functions. My developer friend decided that my InfoPath form was inferior to his complex C# code. I argued with the project manager that while this C# code was nice, it required a developer to update every time someone needed a modification to the form. The end user would be dependent on the developer and while this is ok for the short duration, will this dependency be sustainable in the long run?
My contract ended shortly after the project selected the custom code as my argument fell on deaf ears. I later heard from a fellow SharePoint consultant, that the biotech company underwent a major overall through out their entire IT department. They ended up centralizing their IT department and shutting down the “wild west” approach to IT projects. Custom code forms and sites were shut down and replaced with out of box solutions for simplicity and sustainability.
Yes, I smile secretly now. Where are you now my developer friend? Where are you now?
With that in mind, I want to talk to you about sustainability and working in the cloud.
By that, I mean, O365 cloud. It seems that everything is moving there. What does that mean for businesses and how to maintain a continuous and happy moment floating in the cloud?
The cloud experience does mean, giving up a bit of control to the other side. The servers are now maintained by thousands of network engineers and operations folks. Takes the load off of your company and your IT team to focus on what is important for you.
It’s like renting rather than buying a house. There are give and takes to that relationship.
The benefit of this arrangement is that the stuff you build inside your house, will be taken care of, there will always be hot and running water, the pipes and roof will always be patched and repaired. You will not have to replace the refrigerator or stove if it breaks. The stipulation is that you will not change the structural integrity of the house or bashing holes in the walls. I feel it’s a pretty nice arrangement in my opinion.