SharePoint ‘Customization’ vs. ‘Development’, aka ‘Is It Code?’

One of the great things about being on the faculty at the USPJ Academy is getting to engage in the type of discussions that I recall as being so rewarding in my academic career.  There’s no immediate business crisis at hand, just a bunch of motivated, interested people kicking around ideas to see what makes sense.

I took the “Is XSL Code?” question into the forums in my Data View Web Part Basics course this last week, and there’s been some interesting banter about it.  Everything from “Semantics… Semantics, semantics…” to

But then there are people like my boss who believe that if I call what I do configuration, and I don’t have to compile, build, and deploy in the traditional sense, then he thinks of it as configuration and not coding and, therefore, as acceptable and not subject to our long drawn out Software Development Life Cycle process. So for practicality’s sake, I don’t call what I do coding. Customers get most of what they want very, very quickly, and everybody’s happy.

This isn’t the first time I’ve heard the “if we call it customization, then we don’t have to follow the SDLC [Software Development Life Cycle]” argument.  I’ve certainly played that game a little in client situations myself.

To me, the issue in those cases isn’t whether we’re doing “real development” in our Middle Tier work, but whether the SDLC that is in place for the real development is a successful one that serves the business well.  In the cases where I’ve taken to calling Middle Tier development ‘customization’, the SDLC, while having the best of intentions, has tended to prevent progress and innovation.  Therefore, we’ve sort of end-run the SDLC to get things done for the business.

On some level that always makes me feel a little “dirty”, but I can rationalize it because I’ve provided solid solutions that met the business needs, often coming in under time and budget.  One of my arguments for the Middle Tier is that the exact same SDLC rules ought not to apply. It’s not that good development practices shouldn’t be followed — good development practices should *always* be followed — it’s that the mechanisms are different, so we should reevaluate the SDLC rules to reflect the different methods.

The example I usually use to illustrate this is one where I was doing some consulting for a bank.  The exact same SDLC was applied to the financial systems that was applied to the CSS changes I wanted to make to fix the branding of the SharePoint platform and the paid time off mini-application that I built for a single department. These are vastly different types of systems, which should be viewed quite differently from a governance perspective.  The risks involved are different (real money vs. a logo being a few pixels to the left or someone getting credit for an extra vacation day) and so the SLAs should be different, the development methods should be different, the QA process should be different, etc.  Otherwise, that little CSS change is going to cost a bloody fortune, and in actual fact may just not get done.

So what it comes down to me is a problem of governance rather than a problem of whether it’s code or not.  I would prefer to help redefine the governance model to get it to the point where the business benefits from solid systems that follow reasonable rules over the semantic arguments about what is or isn’t code.  But this is the way the world works sometimes, unfortunately.