Special SharePoint is special

I read an article this morning about SharePoint development that is so unbelievably naive it scares me. It scares me because I know that intelligent, motivated business men and women around the world are probably reading this article, nodding their thoughtful heads, and forwarding it to their developers as an informal contract of expectations. So without further ado, I’m going to indulge my inner jadedness and give you my thoughts.

Software Development Times brings us an enlightening piece called Why SharePoint Development is so damn special!, a pretentious exposition on what differentiates SharePoint development from other development disciplines. In the opening paragraphs, the author (Bjorn Furuknap) outlines his argument:

  1. SharePoint developers need to master a range of skills that “make quantum mechanics seem like Spelling 101”
  2. traditional development methods are teh suck
  3. a SharePoint solution may be consumed or changed by *gasp* other developers
  4. SharePoint developers are shooting a moving target, blind-folded, “without knowing what the target looks like, where it is… what type of ammo… to use…, [or whether they] are in the right shooting range

The rest of Furuknap’s article explains each of these points in detail.

SharePoint developers should be NINJAS with l33t skillz

I know and have worked with SharePoint developers, and I realize that SharePoint development requires knowledge that other .NET development disciplines do not. Like any specialization, there are particular libraries, tool kits, SDKs, etc. that a developer must learn to be proficient. I expected Furuknap to enumerate these particular specifics–after all, he states quite clearly that:

“SharePoint development is completely different than other forms of development in that it covers such a wide range of tiers and technologies.” (emphasis mine)

So what is it that makes SharePoint completely different?

  1. “customizing a solution through the Web interface, or out-of-the-box customization”
  2. “understand extensibility through the middle tier”
  3. “utilize scripting and markup languages such as jQuery, JavaScript, XML, XSL, and so on, usually done through tools such as Microsoft’s SharePoint designer”
  4. “the third tier of development where the programmers reside… using tools such as Visual Studio and Notepad”
  5. “all the varieties of .NET”
  6. “XML… [and] the XML dialects that SharePoint uses”
  7. “[the] intricacies of the SharePoint object models, both the server object model and now the client object model”
  8. “[s]ecurity… that SharePoint does… completely differently from anyone else” (sic)
  9. “Web services, both the ASMX and the WCF type”
  10. “Web service standards and definitions”
  11. “non-SharePoint technologies… such as Active Directory and a number of other authentication mechanisms”
  12. “SQL Server”

A pretty impressive list. Except for the fact that most of these skills are requisite in pretty much any .NET web development job. Only the skills specifically billed as SharePoint skills, or SharePoint extensions to other technologies, would differentiate the SharePoint developer from the average ASP.NET developer. This is hardly the “pirates vs. ninjas” smackdown that Furuknap implies.

Martin Fowler, Bob Martin, and (probably) all other Martins should be ignored

There are some truly great minds in software development. Two of my favorites are Martin Fowler and Bob Martin. They’ve been around. They’ve seen software development grow as a discipline, and have observed, documented, lectured, and probably composed interpretive dances to convey objectively demonstrable best practices in the field. One of these practices, considered by many to be an excellent foundation for writing stable yet extensible code, is unit testing. I will not define it here; I assume you know that of which I speak. But apparently, SharePoint developers are a breed apart, and for them, the Old Ways are not applicable.

“…traditional development methods and experience will only get you a fraction of the way. Unit testing, for example, is useful only for the first few hundred lines of code, after which it becomes more of a burden than an asset… Unit testing and mocking is all the rage these days, and for a very good reason. When you are the master of the code, producing perfect code makes all the sense in the world. After all, any code error goes directly back to you, and if you develop your tests right, your code should have no errors. However, to a SharePoint developer, building code that works is just a small part of the puzzle. As I mentioned earlier, we are not the only developers on a SharePoint solution. In fact, we should encourage our users to modify what we make in order to better utilize the adaptability that is SharePoint’s greatest feature. This presents the traditional developer with a nightmare. If you are not in control over the environment into which you deploy code, how can you test whether your code works? You may set up a mock environment that matches the production environment 100%, and within five minutes, some user may completely alter the entire solution, changing the target you try to hit. This is not the worst part, however. Even if your code runs perfectly at the time you deploy it, it also needs to endure the active modification of users throughout its entire lifespan. Your code may depend on a list having a certain set of columns, but users may change that at any time. They may even remove or replace the entire list, and how will your code run then? The difficulty for a SharePoint developer is not just in writing code that runs perfectly once, but that runs perfectly, no matter what happens to the assumptions you’ve made for your code. There’s no way you can design tests that will properly validate your code against every possible change that users can make, and traditional testing becomes rather pointless.”

Now, since you’re familiar with unit testing (right? RIGHT?) you should spot a few obvious fallacies right away. First, how the hell did he determine that “unit testing… is only useful for the first hundred lines of code”? Seriously. Is there a metric for this? Anyone? Second, unit tests are not about producing “perfect code”. Unit tests are about code isolation. They are about determining if code performs as it should ceteris paribus. Code is only “perfect” insofar as it performs according to expectations, e.g. according to the promises implied by its public API. Third, unless you are the lone developer on a project, you are always building code that others will use and will possibly modify. This is in no way unique to SharePoint developers! Unit tests help establish API consistency, precisely so that others can program against, and/or modify code with the confidence that their changes will not cause unintended consequences. Finally, the goal of unit testing and mocking is not to reproduce production environment conditions. Furuknap insists: “If you are not in control over the environment into which you deploy code, how can you test whether your code works?” This is what integration tests are for, Furuknap. This has nothing to do with unit tests. Or maybe we don’t need those either.

Lock ‘n Load

Furuknap’s last point is that, because “SharePoint is such a complex beast” (his words, not mine), coordinating a SharePoint project among several development teams is like “trying to coordinate firing a gun at a target nobody knows the location of, without knowing what gun to fire, and, of course, without even looking.” In his analogy, the target is equivalent to the “task they are trying to accomplish”. Why is SharePoint development this difficult? According to Furuknap, it’s because of the AGILE AXIS of EVIL!

  • “deliver the first line of code before the ink on the contract is dry”
  • pushing the product to “production by the time the contract is put in the envelope”
  • and “by the time the contract is filed in your SharePoint document repository, your client should be on their way to request the next major project”

In other words:

“…because of the wonders of agile expectations (which are good, don’t get me wrong), we now don’t know what our target looks like.”

Instead, he suggests that:

“The solution to all this is thorough planning and design up front. If you know exactly what you want to build before you write your first line of code, you also know the exact output and can communicate that to other teams. Of course, this assumes that the other teams do the same. In short, plan everything ahead and you won’t be surprised… Well, that was the way one developed solutions before agile principles taught us otherwise, also known as the waterfall era.”

What is hilarious about this elevation of Waterfall is a revelatory statement in which Furuknap states the explicit reason that Agilists embrace iterative development over Big Design Up Front.

“Don’t forget: From the time you release your first code to the time the customer tells you what changes they want, everything about your assumptions has changed again, because users have already started working with and relying on your solution… And then they ask us if we can do this any faster…”

Waterfall methodologies are based on the twin premises that a) all business needs, assumptions, processes, etc. can be articulated at the beginning of a project, and b) they will not change for the duration of the project. These assumptions have been challenged by critics of esteemed ilk (Ward Cunningham, the Martins, Kent Beck, Andy Hunt, and others from Olympus) and have been proved wanting. Agile development relies on a tight feedback loop between developers and customers, so that customer expectations can be met as they evolve, not after the fact. The last third of this article is divided into two need-to-know SharePoint technologies with links to additional reading material. The first is the client object model, which Furuknap listed early on as an essential skill for SharePoint development. The second is Microsoft Business Connectivity Services (formerly named Business Data Catalog – what would a Microsoft technology be without multiple names?), which “provides read/write access to external data from line-of-business systems, Web services, databases, and other external systems within Microsoft SharePoint 2010 and Microsoft Office 2010 applications.” This sounds really important, but it failed to make the essentials list, and so leaves me confused and mostly indifferent. Y U NO LIKE SHAREPOINT At this point you may imagine that I have something against SharePoint developers, but that is certainly not true. Although I can’t say the same for our friend Furuknap, who recommends “booking a session with a psychologiest, because you are quite possibly stark raving mad” if you’re an aspiring SharePoint developer. To be fair, although he has no problem arming crazy people and letting them shoot at moving targets, he does advocate a commensurate pay grade for these Wunderkinds. You know, because they are so damn special. :-) SharePoint development is a growing discipline Mr. Furuknap. Don’t spoil it by turning its uniqueness into a license for ignoring the thoughtful wisdom of the last half-century of development.