Why Developers Write Code – Part 3 – The Developer’s Perspective

Despite the title of this series, I am really trying to answer two questions. The first question started in Twitter several weeks ago and asked when to call someone a SharePoint developer. The answer many people seemed to embrace was that a developer writes code, as in C# or one of the other .Net languages in Visual Studio. I have been a systems developer for over 30 years, but I would never offer as proof the fact that I write code. I would also argue against the twisted logic that would say “since I don’t write code, I am not a developer”. I would vehemently argue against a refined version that would suggest that “since he doesn’t work in Visual Studio, he isn’t a SharePoint developer”, especially since I don’t usually work in Visual Studio.

My opinion, for the record, is that anyone who designs, builds and implements
complex solutions in SharePoint is a SharePoint developer.

With regard to the question posed by the title, writing code is a choice developers make. To understand why developers choose to write code, one has to consider the developer’s perspective. The developer’s perspective is different from that of other people working with SharePoint because for the developer, writing and deploying code is an option. That is an important distinction because a lot of SharePoint development is done by people who don’t have access or authority to install custom-coded solutions. ESUP, other blogs and various repositories are filled with examples of client-side code, tweaks, hacks and manipulations that make wonderful things possible in SharePoint, by people with nothing more than Design privileges. Again, are those people developers? Of course they are.
I do not think there is a definitive “when this is the case, write code” answer to the title question; however, here are five examples of when I would choose to code a custom solution.
When consistency is essential – My use of calculated columns, filters, workflows and instructions to the user met the requirements I was given, but they are difficult to replicate. Oh, I can copy things around, make them part of templates, store them in top-level libraries, etc. but there is always room for error – user error. A program that creates Calendar Entries according to a rule and inserts them at a target URL will work every time.
When the calculation is complex – The calculated column I wrote for CalcStart, with its three nested IF statements, is nearing the upper limit of what I will tolerate. While I have written more complicated formulas in SharePoint, and certainly in Excel, they are frustrating to write, impossible to debug and difficult for others to understand.
When the process is complex – SharePoint Settings pages and SharePoint Designer offer too little in the way of understanding what is going on behind the scenes for me to consider using them for very complex processes. In a development environment, you have the advantage of a Runtime Debugger that allows you to follow the progress of your code. You can interrupt the flow, alter code or variables and restart as necessary. When something goes wrong, my users guess about what happened; I recreate the transaction and see exactly what happened.
When controls are critical – SharePoint suffers when it comes to controls because, in most cases, a person with sufficient permissions can ignore, edit, back fill or turn off a control mechanism. A programmed solution does not provide access between clicking “Submit” and seeing the “Process Complete” box. Consider a process that must update two lists in sequence. A process governed by a Workflow can complete step-1 and fail at step-2. A program, on the other hand, can verify that the user has permission to complete both steps before processing step one, or rollback step-1 when step-2 fails.
When volume is high – Last September, I used a series of custom lists and workflows to implement a football pool in SharePoint. The “enrollment” workflow, the one that built the list of teams, took a bit of time to run. Due to that fact, it was possible for an over anxious player to start wagering before all the workflows were complete. We worked-around that problem by delaying notification of successful enrollment until the last workflow finished. Still, nothing prevented the player from heading to the gaming floor, as it were.
Of course, none of these conditions existed in my little event-replication-and-display exercise so I am happy with the kludge of calculated columns, filters and workflows that got the job done. I plan to revisit this topic a few times between now and SPTechCon in October. If I manage to pique your interest in SharePoint development, you couldn’t find a better conference to satisfy your curiosity than that conference in Boston.