Beats me, but here are some practical thoughts on the topic:
1. If you take a developer with 30 years experience in COBOL programming, and send that person to Java school, they will write COBOL programs in Java. The same holds true for training SharePoint development training. It isn't enough to teach your developer to grind out code according to a certain syntax and programming model. You have to teach people how to think as well.
2. Your newly minted developer will not understand what SharePoint is or how it is used, unless you send them to "power end user" training. It is quite possible to write technically correct, beautifully structured code that completely misses the mark as far as the warp and woof of SharePoint is concerned. SharePoint is all about the end user, and if the developer doesn't take the time to find out what the end user does with SharePoint, then they are going to create bizarre and dysfunctional applications.
3. Developers would rather die, by and large, than go to End User Training.
4. The ideal SharePoint environment needs no development at all. By this I mean that development should be avoided at all possible costs unless you really, absolutely have to have it. Custom code costs tons to develop, tons to maintain, is a source of failure and security breach, and will cost you tons more when you have to uplift to the next inevitable version of SharePoint. The economics are very much against custom code. Custom SharePoint code should be as rare as custom Excel code. You will still need custom code, but it should (IMHO) be your absolute last choice when trying to solve a problem.
5. There are a lot of great companies out there like Bamboo Solutions and LightningTools that make great web parts, BDC tools and the like. Buy off the rack before you develop.
6. Few things are more dangerous than developers with time on their hands, so keep them busy doing something.
7. Let the end user try to find a way to solve a given problem before going to code.
8. There are definite times when custom code is required: The need to aggregate information across unusual boundaries in the system. The desire to create a custom web part that can be deployed everywhere. An example might be a bank that desires to have a web part that calculates mortgage estimates according to the best practices of the organization. That way all employees are on the "same page" when it comes to discussing and selling mortgage scenarios.
9. You aren't going to learn to be a decent developer from an online course, a book, or a series of magazine articles. There is, in my opinion, a mentoring component to learning good development practices. This is one area where I think it is vital to have a live instructor.
10. In the new world, the developers build the Lego's and the end users use the Lego's to build "stuff" in SharePoint. Developers in a SharePoint context will spend most of their time building little bits and pieces rather than grand behemoth software applications. Keep your requierments few, your timeframes short, and your process radical.
11. Customization can take on many forms - Custom workflows are a good idea, custom pages are a good idea as long as you don't violate the ability of the page to support inheritence for features you aren't currently using. Custom data connections are going to be necessary in the long term. Custom web parts will be necessary too. Be careful about custom packages where a site template or definition comes to you heavily customized on multiple levels. SharePoint is intended, IMHO, to offer the end user a series of tools that can be used to build and modify solutions as they arise. SharePoint is not intended, IMHO to provide IT yet another avenue for tightly locked down and non-standard complex solutions. I truly believe that the most cost-effective future is for IT to provide the tools and building blocks, and for the business user to use those tools and building blocks to solve specific tactical problems.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Comments