|
|
|
|
Sharing is Caring > Categories
|
13/11/2008
Hi, Captain Obvious here with blog 10 of one-blog-per-day-until-Christmas. Today's Critical Success Factor is in fact so obvious that I am always stupefied by the number of stuff-ups on this out there in the real world.
The CSF... In Brief
Don't assume that your in-house developers, no matter how awesome they are, will learn SharePoint overnight, and don't blame them if they can't deliver to unrealistic expectations. Give them the training they need, or outsource the work to a skilled and certified developer or services house.
What Happens If You Don't Do This?
If I had a dollar for every time I'd come across a situation where decent ASP.NET developers are thrown on SharePoint projects without training and expected to deliver, I'd be able to afford a bigger block of cheese each week.
In my opinion, SharePoint development requires at least a 3 month full time investment for a developer to become "successful" with the platform. Here's just some of the reasons for this:
- SharePoint infrastructure, and deployment to that infrastructure is markedly different from typical ASP.NET websites and thus has a much steeper learning curve, especially if you want to do it right.
- SharePoint is a massive platform, meaning that only with experience will one understand which hammer they need to use to bang in each nail.
- SharePoint requires you to be a good ASP.NET developer as well as a good SharePoint developer, and even this is a simplification if you think of all the other softer skills that a "SharePoint Architect" would need compared with a traditional "Architect". (Don't even think about putting that grad onto a SharePoint project first - it's not really fair!)
- SharePoint has a "soft" data model that can change over time, which requires some specialist attention when coding against this if maintainable code is to be written.
- Developing against a rich API and framework requires a different mindset (and attitude) to bare-bones development - IMO this is a critical difference.
Here's what I see when developers are not given the appropriate training, mentoring, or at least time to learn with carefully managed expectations:
- Developers tend to look to their old comfortable ways of working, and don't invest the time learning how to architect solutions properly, what the best practices are, or how to deploy properly.
- SharePoint becomes ScarePoint to them - this big beast that they have no idea how to adapt, because a theoretical "big picture" understanding is not there, so they fumble around feeling useless and relying on too much copy-and-paste. (IMO if a developer can't tell you: (1) the difference between a site page and an application page, (2) the difference between customised and uncustomised pages, and (3) what features and solutions are, they haven't been given enough theoretical training to start practical work).
- There's a tendency to customise too much, because of a lack of understanding of what is there out of the box, or on more efficient ways of doing things.
- Even though it's a rich platform, they see it as a nasty black box that they can't control in the usual ways (probably one of the more telling aspects that separates a person who can be a good SharePoint developer, from someone who is better working on a bare-bones app, again IMO. Nothing wrong with either - pick the right "tool" for the job!).
- They spend too much time dealing with technical issues that possibly could have been avoided with training or a more experienced head (though not always, of course), and actually lose a focus on innovating within the project.
- They hate SharePoint for not being able to work as quickly as they could if they could just write some SQL and deploy a few GridViews, and there'll often be a lack of appreciation for the head-start that SharePoint provides (for the right applications).
- They hate you for putting them on the project, and don't get invested in making the project a success.
- Ultimately... your project is not delivered on time, or doesn't work properly, or isn't maintainable, or isn't right anyway because you lost sight of the real hard stuff (users, anyone?) while spending too much time whipping your developer.
Boiling it all down, it's a cost-benefit thing. If you want SharePoint project success, then you may have to spend a little more time or money up front to achieve it. In the long run you'll be thankful.
Practical Tips
- Pick people who want to work on SharePoint, and understand or want the strategic career benefit of doing so. One man's pro is another man's con, so if they don't see it as benefit, then you'll likely be fighting for project success from the start.
- Pick developers who answer "no way" to this question: "if you don't like the performance of C# 4.0, would you build your own language parser?" Seriously - SharePoint is a higher level development framework, and your uber-techos might not like it unless it is a hardcore Visual Studio-based customisation project, which not all SharePoint projects are (or should be).
- 5-day training courses in SharePoint will certainly be beneficial, but remember that "on-the-job" learning will be necessary too. Include contingency in your project plans if you have new developers on the team, and allow them to use it for learning.
- Put noobie SharePoint developers on basic fundamental tasks first such as simple features, web parts, or list/site defs, giving them a chance to learn the framework. Throwing them at a BDC + BI + Excel Services + Custom Column Types project may not be fair initially.
- If nothing else, ask your developers to spend a day reading the first few chapters of this book before they start coding. This will help shape their "SharePoint developer thinking".
- If you outsource, make sure the organisation you are working with has certified SharePoint developers - not just certified ASP.NET developers. There's a lot of bandwagon-jumping organisations out there (fair enuf!)
- Make sure to not mix up your skillsets!
- If you're a frustrated SharePoint developer, maybe my earlier rant will help. Throw it back at your boss to get the training or time you need.
Thanks for stopping by - I'm keen to hear your thoughts.
:) Matt |
|
|
|
|
|
|
|