SharePoint Projects and Technical Debt

Having been in the SharePoint space for several years now I've been on a lot of different SP projects. How many? Well I count fifteen distinct projects off the top of my head, but don't quote me on that. Before my SharePoint days, and with a little overlap I was involved in ASP.NET from about 2004 onwards, and before that there were various VB web and winforms projects, at which stage the mists of time obscure further recollections. :)

There has been a different sense surrounding the SharePoint projects compared to the other technologies. Namely many of the SharePoint projects tended to have a team leader screaming the equivalent of "we need to complete this project asap or we're all finished!!". Indeed I worked on a SharePoint project in 2011 where the Team Leader insisted that every solution for the project should be a banana, i.e. it didn't matter if it was bent as long as it worked. Speed over quality.

Several theories could be explored as to why the SharePoint projects are higher pressure than the others. Unfamiliar technology could have led to underestimating effort for delivery of the requirements. A higher cost of resourcing a SharePoint team could be responsible. Heck, it could be the user excitement at getting their hands on SharePoint meant no-one wanted to wait a minute extra!

My main personal observation from these projects has been this; The high pressure projects incurred a lot of technical debt without necessarily being delivered much faster. Many solutions take just as long to put together done well or done badly. It's just that the high pressure projects tend to have people making mistakes and chasing down the wrong solution path, debugging and firefighting rather than thinking.

Technical Debt is defined here; Technical Debt

This has many consequences, but for me the stand out one is that it encourages SharePoint solutions that do not scale and are hard to maintain. As much if not more than any other type of system you want your SharePoint solution to scale well. For example many of these projects are rolled out to subsets of an organization with the intent to widen usage on a rolling basis. The moment you don't want to discover your solution doesn't scale is when it's being launched to the wider organization and the CEO just made a statement about how cool it is. That's the situation that makes heads roll. [Cue Guillotine Sound Effect - ouch!] :S

If you don't want to end up like the aristocrats that Robespierre took exception to, what's to be done? I guess one of our responsibilities as knowledgeable SharePoint folk is to try and educate our decision makers, project managers, and stakeholders on SharePoint specific issues. There's a right way and a wrong way to do many things in SP, plus of course Reproducibility between environments, testing, look and feel customizations, and User Perceptions (to name but a few things) have their own special issues. We need to spread the word.

I guess also we have to try to secure resource to revisit the technical kludges and pay back the Technical Debt. That's often difficult to sell though - but it's so much cheaper than throwing the system away and doing it again. Or, giving SharePoint such a bad name that the adoption is never successful.

It's wonderful to deliver working systems. It's even more wonderful to deliver good working systems that people like to use, and can scale to meet future demand.

There are no numbers I'm aware of to back up my assertion that SharePoint projects are more prone to incurring Technical Debt than other types of project. I'd be happy to hear some other opinions on it. Post a comment or contact me on the link towards the top of the blog.

Happy SharePointing!