none
Where does development come in?

    Question

  • Hello:

    I'm a legacy application developer, 40 years programming experience, but none of it in Windows.  My company is in the middle of their upgrade to SAP, and the role they see for me down the road (well, they'd probably like me to retire -- but that's not happening!), is in Sharepoint.  I first heard of Sharepoint last October, when they sent me to a seminar -- where I was totally overwhelmed in the first few minutes -- they were discussing things like "Viewstates", "caching", monitoring performance with things called "fiddler", etc...

     

    Since then, I've been studying Sharepoint -- but from a user perspective.  So, I think I'm now pretty far along as far as knowing what it's used for -- lists, libraries, work flows, BI, etc.   But I don't quite understand where developers come in.   Is it in creating new gallery items where the "out-of-the-box" items don't quite cut it? And what tools do developers use?  Is it mainly Visual Web Developer?  Could someone point me to some education  in this area?

     

    Thanks,

    Jeff S  

    • Moved by Clayton Cobb Sunday, April 17, 2011 5:23 PM Programming question (From:SharePoint 2010 - General Questions and Answers)
    Sunday, April 17, 2011 4:28 PM

Answers

  • It's really too much to list.  SharePoint is a gigantic product, and the things you mentioned are the very, very tippy-top of the surface...just basic stuff, but you definitely need to master or at least understand all of that first.  However, you can go so much farther down the rabbit hole before you start getting to the point where we discuss custom dev.  I'm talking about full-blown applications/solutions that still don't require code because of how vast SharePoint 2010 is and how powerful its peripheral tools are.  I guess to give you an example that includes a bunch of things, you can view my quick video here: http://www.youtube.com/watch?v=ADc-0VoS4ZA.  I had to keep the vid under 6 mins, so it doesn't show everything, but here are some features this solution includes that are worthy of note, and keep in mind that none of this required custom code:

    1. Leave data is actually stored in a SQL Server DB and is pulled through to SharePoint through Business Connectivity Services (BCS).
    2. The form is built using InfoPath 2010, part of the Office suite, and utilizes InfoPath Forms Services (part of SP2010 Server Enterprise) so that none of the users of the system even have to have InfoPath installed locally, which means it works on non-Windows platforms as well
    3. The form has data connections to the Leave Accrual data through an External List data connection courtesy of BCS
    4. The form retrieves user profile information through a web service data connection to the User Profile Database using built-in web services.  The profile database is populated with user info from Active Directory on a scheduled basis
    5. The form has tons of logic for auto-populating fields with known data, hiding/showing fields based off user identity and workflow status, detecting the user's manager and acting accordingly, calculating # of days off requested, plus more..
    6. SharePoint Designer 2010 (free tool) was used to create the workflow, which automatically drives the process based on request status and user identity (requests approval from manager, notifies user of rejection/approval, etc).
    7. The workflow dynamically changes permissions of each item so that only requesters and their managers are the only one who can see each request.
    8. The workflow dynamically generates an interactive workflow visualization (not shown in the video) using Visio Services that shows the workflow status while in progress
    9. The workflow updates the Leave Accrual number for the requester after it's approved by the Manager.  The change is written directly to SQL on the condition of approval.

    These are some examples within one solution that just about every company needs.


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    • Marked as answer by Porter Wang Wednesday, April 20, 2011 2:01 AM
    Sunday, April 17, 2011 6:59 PM

All replies

  • This is the General forum, and you'd probably get the best answers in the programming forum, so I'll move it there while giving my own $.02.

    • Development comes in when you can't do it with the MANY out-of-the-box features AND can't do it with other tools in the Microsoft suite that allow for deep customization, such as InfoPath, SharePoint Designer, Excel, Access, PowerPoint, Word, etc.  Don't fall into the mistake of jumping straight to code before understanding if the feature request can be done with one of these tools in a codeless manner.  This is a VERY common mistake.
    • This is more preference, but I also usually choose a 3rd-party tool before resorting to custom development in-house.  Why?  Because people have been doing this for years, and you are just starting, so why venture into the unknown when someone has already done it and proven to make it work in a repeatable manner across hundreds, if not thousands, of implementations.  Good developers may disagree, because they may be able to do it better, but often times clients want a "product" that has a support/maintenance plan that doesn't require keeping a developer in-house just for maintaining one custom app.  I'm not a programmer, so my views here should be taken as such.  =)
    • The main tool is Visual Studio (2010 now).

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Sunday, April 17, 2011 5:23 PM
  • Thanks Clayton...but I'm looking at it from the standpoint of me being that developer that wants to stay in house :)  But I do agree with you to a large extent.  If it can be done with what's already available, then no need to try and customize anything.  As far as 3rd party, I don't know how much of that there's going to be --we're in an industry with just 3 or 4 large players in it, and we're the largest, so we may find that there are some things we would like that aren't out there -- I just don't know.  As to your point about people have been doing this for years and I'm just starting, are you implying that there's no need for any more people to start learning to develop Sharepoint? 

     

     

     

    Sunday, April 17, 2011 5:53 PM
  • 2 main points in response:

    • You don't have to make yourself valuable by creating everything with custom code.  What I'm suggesting is that you learn how to do ALL of that with SharePoint, not just learn the object model and learn to create things from scratch.  If you learn how to "develop" with and without code, then your value will soar even higher.  If you only know how to write custom code in SharePoint but don't know how to do all the things that don't require code, then you'll likely end up creating things that shouldn't be created, or you won't be able to help very much while the company goes full bore with SharePoint use (most of which doesn't require code)
    • Definitely not saying there's no need to have new people learn SharePoint.  In fact, there is a dearth of SharePoint skill out there, especially developer skill.  My point, though, is that you shouldn't code it because you can.  Code because it can't be done any other way (within reason).

    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Sunday, April 17, 2011 6:28 PM
  • Thanks again...I am learning now, things like, for instance, versioning, check-in, check-out, permissions....How to synchronize calendars between Sharepoint and outlook -- that kind of thing.  Also project tasks and workflows.   And  I have in the past done extensive work with excel macros (although that was years ago, and by now I've forgotten most of that)..  But I think these may be the kinds of things you might be thinking of, am I correct?   Because most of this (with the exception of the macros) is the stuff that most of our users should be able to easily pick up, and won't need a developer for.  Or are there other things you are thinking of that go beyond what I've mentioned here, but still don't require development?   If so, could you give me a couple of examples?  And where would I look for more education on that?

     

    Sunday, April 17, 2011 6:47 PM
  • It's really too much to list.  SharePoint is a gigantic product, and the things you mentioned are the very, very tippy-top of the surface...just basic stuff, but you definitely need to master or at least understand all of that first.  However, you can go so much farther down the rabbit hole before you start getting to the point where we discuss custom dev.  I'm talking about full-blown applications/solutions that still don't require code because of how vast SharePoint 2010 is and how powerful its peripheral tools are.  I guess to give you an example that includes a bunch of things, you can view my quick video here: http://www.youtube.com/watch?v=ADc-0VoS4ZA.  I had to keep the vid under 6 mins, so it doesn't show everything, but here are some features this solution includes that are worthy of note, and keep in mind that none of this required custom code:

    1. Leave data is actually stored in a SQL Server DB and is pulled through to SharePoint through Business Connectivity Services (BCS).
    2. The form is built using InfoPath 2010, part of the Office suite, and utilizes InfoPath Forms Services (part of SP2010 Server Enterprise) so that none of the users of the system even have to have InfoPath installed locally, which means it works on non-Windows platforms as well
    3. The form has data connections to the Leave Accrual data through an External List data connection courtesy of BCS
    4. The form retrieves user profile information through a web service data connection to the User Profile Database using built-in web services.  The profile database is populated with user info from Active Directory on a scheduled basis
    5. The form has tons of logic for auto-populating fields with known data, hiding/showing fields based off user identity and workflow status, detecting the user's manager and acting accordingly, calculating # of days off requested, plus more..
    6. SharePoint Designer 2010 (free tool) was used to create the workflow, which automatically drives the process based on request status and user identity (requests approval from manager, notifies user of rejection/approval, etc).
    7. The workflow dynamically changes permissions of each item so that only requesters and their managers are the only one who can see each request.
    8. The workflow dynamically generates an interactive workflow visualization (not shown in the video) using Visio Services that shows the workflow status while in progress
    9. The workflow updates the Leave Accrual number for the requester after it's approved by the Manager.  The change is written directly to SQL on the condition of approval.

    These are some examples within one solution that just about every company needs.


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    • Marked as answer by Porter Wang Wednesday, April 20, 2011 2:01 AM
    Sunday, April 17, 2011 6:59 PM
  • Thanks Clayton,

    For me that was teriffic! Very eye-opening, and it looked like that video was for a competition, and I hope you won ! :)

    This may cause me to re-focus.  I've been thinking that I'm going to have to know client side stuff (html/css/javascript) -- at least from the standpoint of what they do, if not actually being able to be a proficient coder -- and more importantly server side stuff (vb/c#, asp.net, sql_server) -- but sounds like your advice is to just dig deeper into Sharepoint itself. 

    Well thinking as a technician again, tho, in that time-off  application you developed (or any real-world apps you do), do the considerations I mentioned at the start of this thread ever  come into play?   Do you have to consider things like turning viewstates on and off, or what type of caching to use, or where performance bottlenecks occur? 

    Sunday, April 17, 2011 8:28 PM
  • I don't write any code in my solutions, so the answer is "no" to those terms you used mostly, but performance is always a consideration.  You just don't handle these with pure code - you handle them with best practices and proper architecture.  For instance, if I need to query a SharePoint list, I'm going to send a parameterized query so that the filter is applied server-side instead of pulling in all the data and filtering client side.  Things like that are probably very fundamental for you.

    When writing custom coded applications, I'm guessing all those things you mentioned would be planned for, but that's the problem with jumping into SharePoint development.  YOu must first understand the .NET framework and C# coding.  Then, you must understand the SharePoint object model and how it works.  Devs in this forum can give you much better info in this regard.


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Sunday, April 17, 2011 9:36 PM
  • Alright, thanks a lot Clayton...I've learned - well, that there's still a lot for me to learn!

    Sunday, April 17, 2011 10:12 PM