| SharePoint is becoming the ultimate RAD tool for end-users. They are able to deeply customize their portals and compose their own solutions directly in the web UI or using Designer. So where do professional developers fit in?
SharePoint is for end-users…
SharePoint was designed for end-users. Whatever accommodations have been made for developers have been slowly introduced and improved over the last decade. SharePoint 2010 is the first version that can pass as a development platform, in my opinion. While it pales in comparison to other development platforms in some respects, it far surpasses them in others.
Point is, end-users are front and center. They are supposed to be able to help themselves without us. As it turns out, sometimes they can help themselves, and sometimes they can't. Sometimes they are able to compose a solution by creating a list, customizing a view, creating a page, adding some web parts, etc. Sometimes, users need a little extra push to get over a hump. Even then, developers may not be necessary. A power user can train up on SharePoint Designer and InfoPath, customize a form, add a workflow, and even surface external data through Business Connectivity Services.
…but there is room for Developers, too
There are a couple of scenarios where developers can shine within SharePoint.
- Extending the platform. SharePoint offers an impressive set of features. That said, there are many ways a developer can extend SharePoint so users and power users have more tools to work with. This is right in line with SharePoint's goal to empower the users. When we extend the platform, we are not directly addressing a business need so much as overcoming a technical limitation. The business problem is addressed by the user with the use of the new tool (field type, web part, workflow activity, control, ribbon, etc.) we, the developers, created for them. This is a perfect separation of developers and users, and is therefore the cleanest arrangement with the fewest conflicts. This is similar to being a control developer for ASP.NET. You might create a custom control while writing a business application, but there are only so many Teleriks and Infragistics around making a living off of just that.
- Professional, Reusable Business Solutions. While users can go a long way creating business solutions, you have to consider that their customizations are not always portable.
- Oftentimes, users will try something in a staging environment, and then try to repeat the steps manually in production.
- SharePoint Content Deployment, which is designed to move content through the normal dev/staging/QA/production deployment path, only handles content stored in the content database, so may not work every time. It also does not address reuse of the solution in multiple sites/departments.
- There are ways to export and import web parts and site templates and such, but they are rarely the best approach.
Developers, on the other hand, can utilize Visual Studio to package their solution into a WSP file for reuse in any SharePoint environment. The developer packages the WSP, it is deployed to staging, and if the tests pass, the same exact package gets deployed to production, potentially multiple times in multiple environments.
Each has their own strengths
Developers have other advantages, too, like the tools that allow us to do more (features, controls, web parts, etc.) and the technical know-how that allows us to do it better (better architecture, performance, testing, quality, stability, reusability, maintenance). Not to mention we have decades of IT lessons learned in our pockets, such as development methodologies, frameworks (ITIL, CMMi), best practices, and more, to help our projects succeed.
Users have an advantage with quick turnarounds (composing their solutions directly on production for instant gratification) and intimate domain knowledge (smarter about their business processes and their requirements, leading to more accurate process representations in their work). They work faster and nimbler, with fewer layers of interpretation from problem to solution, and less ceremony getting in the way of immediate results. Not every business problem warrants a six-figure (or more) price tag, and the results users and power users can put together often are compelling.
Getting the best of both worlds
So how can an organization get the best of both worlds; the flexibility, speed, and accuracy of a user-created solution, and the stability, professionalism, and performance of a developer-created one? Well, this is where politics and egos get involved. In order to avoid problems down the road, an organization ought to put together guidelines ahead of time. What are users free to do? When should developers get involved? How should they work together? There is no black and white answer here. Navigating these politics come with the job. Some guidelines to consider...
- Look to invest in more professional solutions on mission-critical projects, projects that need to be maintained for years to come, or that need to be shared among departments/sites/workspaces. Keep it simple on others.
- Leverage the strengths of all team members, utilizing whatever assets are appropriate for the task at hand.
Find ways to work together... Consider pairing a developer with a power user to design solutions or perform solution reviews. Or have shared meetings (perhaps Lessons Learned meetings) where knowledge, ideas, and status can be shared among everybody. Each would be surprised what the other is capable of. Document best practices for common situations... a knowledge base (a wiki is great for this). Look for reuse opportunities. If a developer sees a common problem, is there a creative solution that can be deployed as a feature?
These are all common sense measures here. No matter what the makeup of your team, with a little thought, a bit of experience, and a lot of patience, you can find a way to get the best of both worlds.
Thanks for reading,
Lou Estrada |