Ah, the joys of learning a new platform! I actually really enjoy learning new things and wish I had the time to learn a lot other platforms/languages. In this case the new "platform" is MOSS 2007. And yes, the more I get into SharePoint the more I feel it is a platform. It's a fundamental shift in so many ways. I have been working on a SharePoint application for about 6/7 weeks now and feel like I'm getting no where. Seriously! I literally have not produced one deliverable. Unfortunately the project was already a year behind when I got on board. The prior developer had left the company and all his work on the project was mothballed in favor of a SharePoint app. So the pressure is on! And this lack of productivity is killing me! If it were an ASP.NET application I would have been light years ahead right now. What's the problem? Well, I don't want to say SharePoint as a technology is the problem. From what I have learned so far, SharePoint is a very powerful technology. Not that it's a holy grail or anything but it is powerful. And from what I have learned, that power is in the configurability and extendability of a platform that out of the box offers a rich feature set. Instead of writing code, I configure and extend. You are configuring an already built enterprise web application, not writing it from scratch. The code you do write extends. Thus SharePoint as a platform.
There are a few things I have learned thus far from this experience. And remember this is from the perspective of building a full blown web application in SharePoint, not just creating and customizing a collaboration site or something high level.
1) Learn the platform well before trying to produce deliverables. One serious mistake I made was trying to produce deliverables (Or promising I would) before I really knew the platform well. I think part of the problem is I didn't realize how big SharePoint was, now I know, it's huge. I feel like a rat that is brute forcing a maze, it will take a long time for him to find the end. How much better it would be if he were to examine the maze from above. Looking back I should have said I needed a couple of months lead time to learn this platform, then I will start to produce deliverables. I would suggest that anyone building applications in SharePoint give themselves sufficient lead time to learn the platform. And I keep saying platform because there is a lot to SharePoint! Get a number of good books and read them (There are new ones appearing weekly), watch web casts, read how to's, setup a mock application to do some hands on work, read blogs of SharePoint users/experts. Spend a good chunk of time learning it first. If possible get training from a place like SP Solutions.
2) Don't let the "this is all you have to do, its so simple!" hype in the documentation and webcasts make you skip point #1. Web casts and how to's want to sell SharePoint as well as try to teach it. They will make everything look so simple! But like any application there is much more to consider at a high level like deployment, the development process, source control, concurrent development, automation of tedious processes, development environment (OS, IDE, location of software components). And even "small" things like VS solution/project layout. SharePoint offers low level customization and high level customization (And in between), which should you use and when? What are the pros and cons for using each. If I use the high level (Using the SharePoint Designer, et al) how do I concurrently work with other developers and merge our changes (Since I will be developing locally)? How do I integrate source control? If I use the low level how can I be productive? Is there a hybrid approach that gives me the best of both? And many, many more questions (I could go on and on). "Yeah, I can do this really cool thing quickly" but there is so much more to it. In my experience, moving from WinForms or ASP.NET development to SharePoint development will require you to rethink all those high level things you already know. And unfortunately because of the immaturity of the platform and the relative lack of high level guidance it's hard to know exactly how to do things. Things that you would normally take for granted in a traditional app (Because you already have figured them out) are major considerations in SharePoint. I really hope that there is more of an influx of guidance as the platform matures, not just how to do certain technical tasks. This goes back to point #1, you will need to know the platform well first before embarking on designing and building your app so that you can make decisions on the higher level issues.
3) Learn different options without prejudice. For example I made the mistake of overlooking SharePoint designer because in a number of places I read that it was a replacement for FrontPage. That wasn't going to help me! A coworker of mine fortunately looked into it and found that, although it is a web designer like Front Page, it is tightly integrated with SharePoint and opens up the door to do some amazing customizations (Beyond just look and feel) without writing code. Again, point #1!
4) Don't reinvent the wheel. Before creating custom code, see if it can be done in SharePoint on in a "SharePoint" way. Again, SharePoint is a big shift. How you might approach a problem as a WinForms/ASP.NET developer will more than likely be different than how you would approach it in SharePoint. Often the SharePoint way will be quicker (After the learning curve of course), better, fit the SharePoint paradigm and require little or no code. This has gotten me numerous times! Point #1!!!
5) If you need to produce deliverables immediately and you don't know SharePoint you may want to just use traditional tools. As mentioned there is a pretty big learning curve, so if you decide to embark on the SharePoint route make sure that the project will allow for that learning curve. Otherwise you may be putting yourself in a stressful situation. Don't underestimate the amount of time it will take to get up to speed with SharePoint from both a technical and high level perspective.
Ok, no more rambling. Bottom line is that SharePoint is very powerful and very configurable. And I bet over time it will become a standard M$ RAD tool. There's no reason to implement all these common features from scratch when you can use a configurable, extendable platform that already offers them (Think Java, .NET Framework, RoR, etc). But go into it with knowledge as its a fundamental shift from using the classic WinForms and ASP.net approach.
I'm not going to post technical or high level guidance yet as I am still learning and figuring things out, but at some point I will definitely share that.