The relative effort of SharePoint 2010 vs. 2007
SharePoint 2007 was the best demo-ware ever. It’s like going to the pet store and seeing a great dog that does backflips all kinds of tricks – and it really is a smart dog and it does all those tricks – but when you get it home you realize that what you need is a dog that gets the paper. SharePoint 2007 can be trained, but is fundamentally a platform where Microsoft's priority was to get the infrastructure right – to make it trainable and extensible. Because it was great demo-ware it caught on like nothing ever before and became a billion dollar product. But adapting it to specific uses did take serious effort because the priority was the infrastructure rather than the tools to build solutions on that infrastructure. Thankfully Microsoft did spend time explaining how to train it (a lesson they learned after SPS 2003), but the effort was a significant part of delivery.
When building SharePoint 2010, the infrastructure was there so Microsoft focused on making it easier for people to build solutions. You still need a vision of what the solution will be and a design process to work out the details, and you still want people who deeply understand the platform in order to develop effective solutions. But the development story is now much more about configuration and less to do with programming. In both cases, both configuration and programming are supported with much-improved user interfaces, especially for common scenarios.
A gut estimate of the difference in effort goes like this. Counting "lines of code" and "effort of configuration" solutions consisted of ~50% configuration and 50% code with SP&T 2007, and programming took up 80% of the time. With SharePoint 2010, the same solutions can be composed with 90% configuration and 10% code, and on average programming will account for about 20% of the build time.
To consider an actual project, we delivered a knowledge management solution using MOSS 2007 including customized collaborative sites and a document repository. The bulk of programming time was spent on: custom field types (some cascading) to pull lookup values from a web service, rewriting content type propagation (Soren's code and Gary's extension do not cover important cases), building custom web parts to aggregate information from disparate sources, building workflows to approve and provision new sites, writing event receivers to tag and route documents, and building a custom site directory to display the sites a user belongs to. Thinking through these components, easily 90% of it would now be covered by configuration, and a 2010 solution would take about 50% less effort to maintain and update post-launch.
It’s hard to say how much shorter delivery time will average. If lines of code accounted for 80% of time before and 20% now, and a “unit of configuration” takes half the effort of development, then all-code would be an index of 1 (= 100% * 1), 2007 presents a relative effort of .9 (= 20% * .5 + 80% * 1) and 2010 falls to .42 (= 80% x .5 * 20% * 1). That's about half the effort (or resources). The architecture and design cycle should change little, if at all. Prototypes are more likely to provide a starting point for development (e.g. Visio flowcharts and SharePoint Designer workflows can now be imported to Visual Studio for finishing). Branding will change little, though there will be less redundancy (e.g. no additional effort to rebrand application pages). All work still requires testing and a feedback loop with sponsors and users.
Remember that these are all from-the-gut, invented numbers and non-scientific equations, and what counts are our real experiences and projects just now underway. So what do you think - close or far off? Was your index lower for 2007? Do the SharePoint 2010 components better support your scenarios and if not, why?