I attended the Seattle Facebook Developer Garage tonight and kudos to the folks who organized the event!  It was a fantastic event that was literally bursting at seams with people.  There must have been over 200 people at the event from all over the Pacific Northwest.  I have used facebook for some time and get how pervasive it has become, however, there was a large number of people coming up with very elegant/simple solutions to interesting problems.  Maybe I’m late to the party here, but these social networking platforms are enabling real businesses that are services thousands to millions of users.

Onto the point of the post: At the event, there were a serious of developer and some business oriented talks (each talk was about 10-15 minutes).  All was fun, the crowd was laughing and listening- doing what happens at most of these user group type talks.  Then we got into a design oriented session that included the word “beautiful” in the title.  Although the speaker had some great points, people did not react the way they had reacted to the other sessions – this was a talk based on subjective characteristics and a series of “steps” that we could follow to achieve these attributes.

I realized that we had crossed a type of boundary between things that could be proven and ideas/methods that seemed to be the speaker’s opinions.  I think this is a common problem when people speak about best practices/methodologies.   I have seen this reaction many times – I’ll even admit that I’ve seen it at talks that I’ve given before.  I guess there’s no better way to learn something that to experience it for yourself.   So what do I think this speaker could have done better when talking about his methods:

1. Prepare the audience for a session on “best practices.”  Developers are really good at finding holes in things.  It’s important for people to get in a mindset that these best practices are just one of potentially many means to the end.
2. Give examples.  Supporting each of his principle with a number of examples.  Some that clearly followed it and others that did not.
3. Understand important metrics.  Identifying metrics allow people to track and optimize them.  Not all metrics are created equal, but metrics are important in understanding the dynamics of the system/progress.
4. Identify stakeholders.  Personas are just as important to the method/best practice as they are to the system that is being created.

In the spirit of a “best practices” blog post, I’ll be up front about my list of principles J.  These are some principles that I’ve learned over my time working on software methods and it’s not intended to be an exhaustive list.