Thursday, March 31, 2011

A new methology for planning SharePoint Projects - how to win a tender

Today I want to discuss a methodology I have been working on for a while now.
For the last ten years, when developing a solution architecture for clients, I have always stuck to the KISS principle. If you are unfamiliar with that one, it means "Keep It Simple, Stupid!" - which is a good advice when you submit your solution to the review of your peers - other technical specialists and assorted IT professionals. A simple design usually wins through simplicity - it is easy to grasp, easy to implement and easy to maintain and expand on. By KISSing other technical people, you usually get the design you want approved. If you want to read more about KISS, see the wikipedia article about it: http://en.wikipedia.org/wiki/KISS_principle.

The problem I found with KISS is that when you pitch your design to other types of audience, for example upper management, it tends not to be accepted. Initially I thought it may be that management are less prone to like being called "stupid" (which is why I always phrased it "Keep it simple, silly!" - but that never improved things much), but the more I thought about it, I realised that those audiences just expect more out of a solution design than just simplicity.
In other words - KISSing the upper management is not enough.

This is why I decided to come up with my own new principle that extends KISS and adds the things that upper management really wants from a solution architect:
Keep It Simple, Stable, Available, Scalable and Secure.
By KISSASSing upper management, you are almost assured to get the project you are tendering for, or get your solution approved. I think KISSASS should be practiced - do not think you are ready to KISSASS today - it does require a lot of experience - which is why more experienced professionals may get projects over others - they are much better KISSASSers.

I intend to come up with some KISSASS best practices, KISSASS guidelines and perhaps some flow charts explaining how you should practice KISSASS in other aspects of life. If you have some ideas - please share them with me in the comments for this post.
But in the meanwhile - have a great April!

Monday, March 21, 2011

SharePoint 2010 developer training - thoughts

I spent the entire last week in Perth (Australia) delivering developer training to 5 students - and it was great. We covered the basic skills that every sharepoint developer must have, and we talked about what skills they should still learn after the course to enhance their skills. I feel this course (written by MVPs from all around the world, guided by my friend and fellow MVP Randy Williams from www.synergyonline.com, is the best course material available to train SharePoint developers.

Why? first, the labs are excellent - we only had one or two cases where the text in the lab (instructing the students) were slightly off. Synergy Online's quick reaction to fix and modify the labs to correct those typos is one of the reasons I love working with them.
Next, there is the chapters themselves. In 2006, a SharePoint development course could be completed in 3 days or so. Today, it is impossible to teach all aspects of SharePoint development in a five day course. Since students are working people, and cannot spend two weeks learning everything, prioritization is most important, and Synergy Online did a great job figuring out what most developers need to know, and then balancing it so that even within a specific topic, if the topic is too long to teach in 2-3 hours, the class teaches enough for the students to know how to begin and to know they should look into more details when they are back at work before starting a project using those skills.

The only recommendations that I have made to Synergy Online was to drop the Business Intelligence chapter, as while it is important for solution architects, it is less developer oriented, and a much more important chapter that should replace it would be custom field types. I also suggested that we include EditorParts in the web part chapter - at least one code sample so that students can carry on after the course knowing that this functionality is there.

My very favorite thing about training is to tell students about real life scenarios that I had with the technology. For example, in the chapter about querying sharepoint data (comparing SPQuery, SPLinq, and more), I can tell about projects that I had where I built web parts that aggregated sharepoint data, and even open the source code for a web part I have developed in the past and run through the code. This way the students get to see more complex examples of what they see in the lab, and I can even give "best practice" advice about things like error logging and error handling in web parts - as a side note.
I feel this adds so much value to the course...maybe I should be asking for tips at the end of the week?

Next month I am delivering the same course again, this time in Canberra (my home town). If you are seeking developer training and can take a week to be tought by myself - register now at the Dimension Data web site (make sure you choose "Canberra" as location - the other locations are not courses that I am teaching. If you cannot make it to Canberra, by all means register to one of the other ones - the other Syngery trainers are highly professional and knowlegeable - for example, Eric Cheng is a fantastic trainer and I enjoyed teaching with him in the past).