Go to page: 1 2 

Printer Friendly Version

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.

Go to page: 1 2 

Printer Friendly Version

Other Resources

from Intranet Journal

Intranet Journal Discussion Forum Hasta La Vista, Windows Salesforce.com Offers Invitation-Only Collaboration Ten Leading Open Source Innovators

from JupiterWeb