From all the new features in SharePoint 2010, most seem to be focused around developers and development productivity. There are lots of talk about the new Visual Studio 2010 tools for SharePoint, the “Business Connectivity Services” and sandboxed web parts.
Does this mean that we will spend more or less time writing actual code?
At the SharePoint Conference in Las Vegas, I sat in on the “best practises” session where few new topics were covered. 90% of the material was taken from existing SharePoint guidance documentation and sandboxed solutions were touched upon. However, one single line stuck in my mind - “developers, know your platform”.
I have time after time seen developer-heavy implementations of solutions that could have been created using configuration of existing components in SharePoint. At the same time, I have seen solutions where one or two features of SharePoint have been used (and abused) to encompass all scenarios. This is simply because the implementation has been done by someone who has limited knowledge about SharePoint as a platform.
From a developer’s point of view, here are the major changes in SharePoint 2010:
- Less code and more configuration
- Less hand-hacking of definition files and more exports of prototypes into solution packages
- Less custom solutions and more reliance on out-of-the-box solutions combined with empowered end users
As an example: I recently had very similar requests from two very different clients. They both wanted “powerful” reporting across data sources and against multiple criteria. It also needed to be easily reconfigurable to fit future needs. Both clients mentioned analysis and data mining in loose terms around “dimensions”. This could easily have been steered into a long and expensive project with OLAP data warehouses, reporting models, Excel Services and Performance Point Server, and the developer in me started talking about this approach on both occasions. However, when I demonstrated what could be achieved by connecting Excel and Access directly to the SharePoint list data and performing pivot reports against the data, both clients were more than happy. In the end, I ended up proposing more time on end user training and configuration and hardly any custom development.
The same story can now be applied to requirements surrounding accessibility, standards compliance, integration of line-of-business systems and external data and workflows.
SharePoint 2010 does empower the developer, but more importantly – it makes the development cycles shorter, provides better tools for packaging prototypes into solutions and further empowers end users to interact with the platform with rich client tools.
Out: Large development teams. In: Developer consultants!
