Intranet Journal
The online resource for intranet professionals

Managing the SharePoint Learning Curve

1/2/2008

The core reason for pursuing development in Microsoft SharePoint at all is the ability to maximize productivity. While it may be fun to work on the latest and greatest technology, most development is done for a business purpose. Because development is done for business, the most important reason to work with SharePoint is improving productivity. Productivity might be viewed from the perspective of the time saved by not having to develop features that users may want but which are difficult to implement.

Productivity might also be viewed from the perspective of flexibility to adapt to changing requirements in the future or reusability of the software that is developed between different parts of the solution. No matter which way you look at the problem there are some distinct advantages to developing with SharePoint. However, on the other side of the fence there are some barriers to productivity when developing with SharePoint, not the least of these is the learning curve that every architect and developer must overcome when building SharePoint-based solutions. In this article, we'll look at this learning curve and how to make it easier.

Learning Curve

SharePoint is a robust platform. Developing with it is a consideration for any organization that is developing solutions in ASP.NET. It's hard to miss the tight Microsoft Office client integration including version control, check in/check out, and workflows. It's equally hard to miss the idea of building applications in units of parts of pages and not complete pages.

However, the power of the platform comes at a cost. In order to gain the advantages of the platform there can be a fairly steep learning curve. Part of the learning curve is understanding ASP.NET at a deeper level, some of the learning curve is learning ancillary technologies that SharePoint uses, and some of the learning curve is unique to SharePoint. When you add the amount of learning together it can be overwhelming and frustrating to any developer, development lead, and development manager.

More From Jupitermedia

10 Open Source Apps for Enterprise Users The Cure for Intranet Burnout Why Ubuntu Linux Tops Debian IDM Dreamweaver Tutorial Creating a PHP-Based Content Management System Top Intranet Trends: Usability, Access, Personalization The 2008 IT Salary Guide If you want to comment on these or any other articles you see on Intranet Journal, we'd like to hear from you in our IT Management Forum. Thanks for reading. - Tom Dunlap, Managing Editor. FREE IT Management Newsletters bITa Planet CIO Update Intranet Journal Update Datamation IT Management Careers Datamation IT Management Update Grid Computing Planet HTML E-Security Planet HTML DRM Watch HTML

Most ASP.NET developers who've been doing ASP.NET development for a few years would say that they're pretty good ASP.NET developers -- and rightly so. However, SharePoint as a platform exploits a wide variety of ASP.NET's lesser known features.

SharePoint takes advantage of ASP.NET 2.0 master pages. The Master Pages feature allows the developer to develop one common template which contains the core navigation and framework for pages -- and then fill in the blanks with the pages themselves. Understanding how pages come together in SharePoint means that you'll need to understand the relationship between master pages and the pages themselves. For instance, master pages can contain content inside of a placeholder. When content is in a place holder in the master page that content is used whenever the page doesn't contain a reference to the placeholder. This minimizes the amount of code in each page while still allowing for special circumstances. The default master page in Windows SharePoint Services includes 31 placeholders that pages can fill in. A typical ASP.NET application developed inside an organization has less than ten. In many cases master pages have less than five placeholders.

The Web Part technology that SharePoint is built upon is a technology that was rolled into ASP.NET 2.0 -- but one relatively few developers have played with as of yet. Web Parts expose the concept of configuration based development. In a nutshell configuration based development is building components that behave differently based on the configuration information that is provided to them.

One of the features of web parts that most developers haven't had experience with is web part connections. The web part framework allows you to connect the output of one web part into the input of another web part. Building solutions that can be composed of multiple web parts chained together like paperclips isn't a normal approach for most developers. It will require a change in perspective to get the most out of the web part framework.

Ancillary technologies that may not be in a typical ASP.NET developers arsenal include XML and XSLT. Even if you've got a more than passing understanding of XML you may find that you've still got something to learn. Most of the XML in SharePoint uses a namespace. That means that using XPath to pick out nodes from the XML requires the use of the local-node() function or inclusion of a name table in each call. Similarly the XSLT used in some places in SharePoint numbers hundreds of lines long so even decoding what's happening in the style sheet transformation can be a challenge.

From a design perspective Cascading Style Sheets (CSS) are the preferred way to implement the colors and images which will make the page look the way that it should look. SharePoint both takes advantage of CSS -- and does not. The CSS sheets that SharePoint uses can be quite long as each element on the page is targeted with different colors, images, and classes. Determining what classes to override in order to get the look and feel you want isn't a trivial matter. On the other side, there are some items which cannot be overwritten. SharePoint sometimes emits hardcoded values in the HTML itself that CSS can't override. A solid understanding of CSS is essential to determine what can and cannot be done.

SharePoint adds to this mix its own set of new technologies. From the options you have for branding your sites, which includes site definitions, site templates, master pages, and themes, to delivering your solutions through a technology called Solutions Packages, SharePoint does have its own set of things to learn. Most of these items are well documented at this point. For instance, there are at least four publically available articles on how to create a SharePoint Solutions package.

Managing the Learning Curve

With so much to learn there's the potential of eroding any productivity gains by investing in overcoming the learning curve. However, there are some strategies -- none unique to SharePoint -- which you can leverage to keep a team on track.

Abstract Away (Hide)

Developers familiar with the façade design pattern will already know the benefits of abstracting away details from developers. The façade design pattern hides complexity from the developer by providing easier interfaces to the patterned objects. Like the Hollywood movie sets where only the front wall of the buildings is real, the façade design pattern hides the details of the buildings behind an easy to recognize façade.

The idea that you hide unnecessary complexity from developers has been a common theme for the industry for decades. Where developers in the 60s and 70s needed to understand how processors work including accumulators and counters and other components, developers today don't need to understand any of this. Third and fourth generation languages like C, C++, C#, and Visual Basic have made it largely unnecessary to understand processors. Relational databases, XML and core libraries have largely eliminated the need to understand complex data structures.

In order to prevent productivity from leaching away there's a need to develop facades that eliminate the need for developers to completely understand every aspect of the platform they're working on. This will minimize the amount of learning time and allow the developers to focus on those aspects of the platform which are essential for them to understand.

Fundamentally this book discusses an abstraction of the details of web part development. We're talking about replacing the details of web part development with a skill that is a much easier transition -- user controls.

Divide and Conquer

When planning strategies for development teams it's fairly common to think about individual developers, team leaders, and architects having unique individual skills. Whether it's an artifact of their history before joining your organization or whether it's something that's become ingrained with them during their tenure at your organization, specialties develop among any group of people. The divide and conquer strategy relies upon this natural bias towards specialization by encouraging targeted development of depth within an area.

One team member might become an expert at the ASP.NET event firing sequence and managing reposting and repopulation problems, while another team member becomes an expert at cleaning up garbage collection, while yet another team member becomes an expert on caching. This specialization can be helpful in reducing the amount of learning that any individual team member has to take on.

It is often helpful to focus a developer on the techniques to abstracting web part development, while encouraging other developers to invest in learning design issues such as master pages and CSS sheets. Cross training will eventually become an issue as you seek to provide some stability should a team member leave the team -- however, these are secondary issues which are easily solved by "lunch and learn"-type sessions where each developer is asked to do a mini lunch time presentation to their peers on their area of expertise.

Small to Large

Another way to manage the learning curve is to make sure that it's a curve and not a vertical jump that developers need to make. This is done by arranging the tasks in the project such that the easier tasks -- from a learning perspective are arranged first with the later tasks being more integrated into the environment. This allows developers to learn about their environment more slowly and therefore they don't have to invest as much time directly in learning the new platform. They learn the platform through their tasks.

This strategy does, however, have a non-trivial risk. Because the higher integration points are not fully understood and they are delayed until the end of the project, it's possible that one or more fundamental assumptions about how the technology works or how things fit together may be invalid and it's possible that rework will be required. This risk can be mitigated by having an architect or consultant on the project who is experienced with SharePoint so that they can steer the developers away from areas where their assumptions might not be valid.

Use Proper Tools

One of the most powerful things that can be done to minimize the impact of the learning curve is to ensure that the developers have the right tools. Consider for a moment the state of photography in the world. Photography is getting better and this is due in no small part to the invention of the digital camera. Now professional photographers and amateurs alike can see the results of their work instantly -- and make adjustments to get a better photo before the subject or lighting is gone. If you discuss digital photography with any professional who's using it you'll likely find that their ability to see what they've done, experiment, and quickly correct their mistakes have made digital photography an important tool for the professional photographer.

Perhaps the most obvious example of this in the development world is an XML editor that supports XSLT. Editing XSLT transformations in tools that don't support running the XSLT and seeing the output means much longer cycles, and less time spent exploring how different constructions work in XSLT. However, having the tool can make building XSLTs so easy that it's hard to see why you never used them before.

When looking at the SharePoint learning curve for your team, evaluate where the skills gaps are and determine if there are tools which can make it easier for them to work with the technology -- and learn in the process.

Training Resources

No discussion of managing a learning curve can be completed without some mention of the training resources available to the developers. This is because the amount of time spent learning is inversely proportional to the training resources available to them. The quickest way to get an answer is from another human and because of that having a mentor or coach through the project can substantially reduce the amount of time necessary to learn something new.

Barring the ability to make an expert available making computer based training, books, and other training materials available to the team can dramatically reduce the amount of time to learn something. Speaking from a personal perspective, having the right book on hand can take something that's hours of work to research on the Internet and can turn that into a 10 minute read of a single session. It doesn't take too many times of reducing a four or eight hour research sessions into 10 minutes before resources pay for themselves.

Conclusion

SharePoint is a powerful tool with an impressive set of technologies that it leverages. In order to get the value out of SharePoint that want, it may take some work to determine how to keep the necessary learning to a minimum -- and make the learning that must be done effective.

email this page

Tutorials XML Basics and Benefits Removing Spyware Build a PHP CMS Microsoft's SharePoint and more at: Intranet Journal's Tutorials

Intranet Journal Favorites Creating a PHP-Based Content Management System The Spyware Guide Introduction to Microsoft SharePoint Portal

Intranet Journal Part of the EarthWeb Network Managing Editor Intranet Journal Tom Dunlap EarthWeb Home Page Jupitermedia Home Page Media Kit