Glenn Wiley's Blog

A co-worker of mine sent out a link to an interesting blog post about what it takes for a successful SharePoint implementation.  This is yet another reminder of the demise of the software generalist.  Back in the day, it was reasonable to be an expert in general software development.  When I think back to when I first began software development, a company generally had a group of Mainframe programmers and another group that did desktop development.  Most of my colleagues had similar backgrounds and you could reasonably have someone who was an expert in Windows development that pretty much knew how to build all of the pieces needed for an Enterprise system.  Even a few years ago, if you were a VB guy like myself, you could accomplish quite a bit as a VB programmer.  Lately, every time I read through my blogroll I find myself reading only a few posts, picking and choosing what to dig into.  My current position is focused on SharePoint development.  I'm amazed at how many different technologies come together in SharePoint.  I've known plenty of developers who turn their noses up at SharePoint developers.  It's not unlike the disdain a VB6 programmer used to get from C++ programmers who considered VB a toy language.  The reality is that many of the technologies you see in today's IT infrastructure come into play during a SharePoint implementation.  I admire the SharePoint MVPs a great deal, because I know how many different hats you need to wear to be considered a SharePoint expert.  A good SharePoint developer is every bit a .Net developer, and much more.  In fact, you need to have a broader understanding of different technologies than your average .Net developer needs.  I've been overwhelmed with the amount of things I've had to brush up on or just plain learn in order to understand what turns out to be only a piece of the SharePoint puzzle.  I started working with .Net development right from the start, and I've been fortunate enough to have had experience developing Windows clients, web applications, web services, Windows services, console applications, mobile applications, you name it.  Most .Net developers are focused in just one area, perhaps web development, or smart client development.  Now though, even being adequate at developing all of the kinds of applications I just mentioned is out of reach.  Windows Forms is now Windows Presentation Foundation - an entirely different animal.  ASP.NET is more than churning out C# or VB.NET code with some HTML.  You need to understand JavaScript (there are multitudes of JavaScript libraries a web developer is expected to know - MS Ajax, jQuery, Prototype, script.aculo.us, etc.), CSS (an art form in and of itself), the backend system (SQL Server, Oracle, etc.), and many other web technologies such as Silverlight, Flash,...the list goes on.  And the amount of new development tools and technologies coming out of Microsoft recently just blows me away.  There are entire frameworks to understand just to be proficient in developing one small piece of an Enterprise system.  Windows Presentation Foundation for smart clients, Windows Communication Foundation for distributed systems, Windows Workflow Foundation, .Net 3.5 with LINQ, the upcoming Entity Framework, IronPython, IronRuby, the DLR, and ASP.NET MVC.  I could easily spend all of my free time just understanding one or two of those technologies.  Forget trying to even come close to being able to be proficient in several of them.  Forget researching something for good, geeky fun, like functional programming with F#, or playing with XNA Game Development.   By the time you really get a grasp of one of these new technologies, something else comes out to make it obsolete.  And did I mention the amount of time needed to keep up with the latest development methodologies (like Agile) and best practices for your field of expertise?  I learned long ago that there are only 24 hours in a day, at least 8 of which is dedicated to doing real day-to-day work for customers - not playing with the latest bits from a Beta 2 release or reading the latest LINQ book I ordered from Amazon.  I look over at my bookshelf - I have many books on but a few of these technologies, and I have tens of thousands of pages of material that I will never get through, and it'll all be obsolete in a few years (or less).  Keeping up with technology reminds me of being back in school, trying to cram for a test after staying out too late, and rushing out to get the Cliffs notes, hoping to learn enough to get by.  The difference now is that I'm not trying to do it at the last minute because I was irresponsible - I'm just trying to keep afloat in the sea of technology.  The software industry is still young though.  It's definitely evolving towards specialization. 

Back to SharePoint...this got me thinking about an episode of the Verminators I just watched the other night.  If you haven't seen it, it's a reality show that follows around a bunch of guys in a pest control company.  I was thinking about how these guys work in a given day, and that's really not unlike how you have to work on a SharePoint project.  They had a guy who was the "Termite Guy", a guy who was the specialist for working with sensitive customers, someone who was the "Bird Expert", another person who was the "Bee Guy", and yet another who specialized in roach infestations.   The point here is that even though these guys are all in pest control, they specialize in one particular area.  Each one of them has experience with one aspect of pest control and is considered an expert.  It really shouldn't be any different with a SharePoint deployment.  You need someone who specializes in daily administration, someone who understands infrastructure, someone who specializes in customer management, someone who specializes in web branding, someone who specializes in custom ASP.NET development, someone who specializes in workflow, and so on.  Each deployment is different, so you'll need different experts...just like the pest controls guys.  They had one customer with termites, birds and rats.  Each pest needed a different expert.  I think this is why I've enjoyed getting into SharePoint.  I can now see something that I can focus on.  I don't have to worry about whether I can do smart client development, web development, database development, or what have you.  I'm able to concentrate on SharePoint and my role in a deployment.  I sure won't be able to master all of it, but I'll try to be the best with the pieces I work on.