Recently, I was asked to make a return visit to a customer for whom I had built a customized SharePoint web app to do “refresher” round of knowledge transfer to folks who would be entrusted with support and deployment. It was only for an hour, and in that time I did a soup-to-nuts flyby of the highlights along with some deep-dives into code when asked about particular features.
While describing the schema for an external database we’re using to gather data, one of the attendees asked me why I opted for a single flat-file and not a series of relational tables, etc. as this would alleviate “maintenance headaches” down the road.
I reminded the fellow of the theme (which I had explained in a prior session) that guided my development on this solution : The simplest thing that works. Using this as a “knothole” test, I triaged and pared features and design down to keep the project achievable within the 4.5 week timeframe I was alotted. Had I chosen to modify the schema as he suggested, I’d actually have complicated my solution on the reporting end, which uses a series of pivot charts in Excel connected to the datastore.
(I should also hasten to mention that another influence on my adherence to simplicity for this project was the failure of a similar, prior solution developed by another consultant that ended up gutted and a shadow of its former self because the customer’s support team found it “too complex” and failed to perform as advertised.)
This episode brought to mind a couple of the rules of Unix design philosophy:
2. Rule of Clarity: Clarity is better than cleverness.
6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Beyond the example of the simple, flat schema for the data store, I employed these rules throughout my design and development of the solution, leveraging as much OOTB functionality from SharePoint as I could and only treading into custom code where I couldn’t avoid it – and even then, using low-impact techniques.
Where I couldn’t build functionality in a reasonable amount of time, I recommended purchasing pre-built web parts. Where I couldn’t find ready-made web parts for a report user interface, I built one using client-side techniques (HTML + jQuery + AJAX + SharePoint web services) that avoided creating heavy-weight, server-side code. Where we needed adhoc reporting capabilities because the customer was unsure of how they wanted to drill into data, I recommended using Excel with a SQL connection instead of SQL Server Reporting Services.
Now, I didn’t come to these solutions immediately; in fact, as I know from years of experience, good design emerges iteratively. No amount of clever Big Design Up-Front planning ever yields this quality of results. In-line with just about every engagement I’ve undertaken within MCS, had I stuck to the original plan, I’d have delivered a solution that would have been complex and substantially off-the-mark. However, by breaking my time down into weekly iterations, I was able (with the customer’s guidance) to zero-in on the highest value features they needed while making key compromises with their blessing.
Thus, a fundamental tool for communicating these design decisions to the customer and garnering their support were my weekly demonstrations each Friday where they could see the working solution come to life and have direct input: “Yes, I like this; no, that totally misunderstands what that number is for; I am disappointed we can’t do this other thing, but I now understand why – maybe we can look at this for v2.00”.
In this way I was able to enforce the Rules of Clarity and Parsimony: “The simplest thing that works.”