On Developer Communities: You Can Tune A Piano But You Can’t Tuna Fish

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

  1. First, you need a team builder
  2. You can run a company like a user group, but the inverse is not always true.
  3. Quality always works.
  4. People are not resources or assets.
  5. Don’t go away.

Each hypothesis is accompanied by one or more “anti-hypotheses” – clues that you are not participating in a sustainable developer community. 

Every Square Is A Rectangle…

… but not all rectangles are squares. You can run a company like a user group, but the inverse is not always true. You can tune a piano but you can’t tuna fish. What do I mean by all this?

User Groups are big extended communities – almost a family to some members. Meetings are anticipated. Folks even get excited about the newsletter emails! Communication is required, and it must be clear, concise, and consistent.

Just like in corporations.

But there are distinctions to be made. User Groups are nearly always volunteer efforts – even when there is sponsorship money involved. As such, leadership has to exercise patience and maturity when asking things of membership or other leaders. Demands are verboten. Ultimatums are useless. Authority is an honor.

Anti-hypothesis: If leadership wields authority by making demands and delivering ultimatums, you are participating in a dysfunctional community.

Leadership is a privilege.

When there is money involved, the collection and dispersing of finances must be transparent to leadership at a minimum, and should be reported to membership yearly.

More Of Our Story

When we organized the first Richmond Code Camp, companies in the area began asking us about sponsoring User Group meetings. Through sheer serendipity, one company in town pretty much had a lock user group sponsorships. As president of both groups, I now began fielding embarrassing questions about the situation.

At the same time, I wanted to give away cool swag at Code Camps. When I say “cool swag” I mean an X-Box. Although a mediocre salesperson, I could not convince Code Camp contributors to contribute an X-Box. So I began searching for an alternative… “maybe we could buy an X-Box if only we had some money” I thought… (which again reminded me of the Steve Martin shtick mentioned in the first post).

Darrell Norton is an MVP with an MBA from Richmond. If you have a local MVP who has an MBA you already know this: those guys come in handy now and then! Darrell had written a business plan for developer communities years earlier while working in Virginia’s Tidewater region. He circulated it some back then and got at least one taker: a user group from NoVa. It had worked very well for them.

The plan consists of multiple tiers of sponsorship: platinum costs the most but keeps your logo on our website and all communications for a year. Platinum sponsors also get to choose two monthly meetings to sponsor, for which they provide food for the attendees. Gold, Silver, and Bronze levels cost progressively less and offer progressively less to the sponsor.

I approached the company that held the lock on Richmond User Groups and laid out the plan. They had steadfastly supported the developer community for three years. I was going to open up the groups to outside sponsorship using Darrell’s plan, and I would give the company holding the lock three years at the Platinum level for both the Richmond .Net Users Group and the Richmond SQL Server Users Group – free. They agreed.

With our first sponsorship check in late 2006, I formed Richmond User Groups Corporation using LegalZoom. An S-Corporation in the Commonwealth of Virginia, we became a not-for-profit corporation and did not file for charitable status. This preserved the option of selling stuff (sponsorships).

If you plan to follow a similar road, you definitely need to check on the laws in your state, province, and/or nation to see what’s allowed and what isn’t.

The corporation sheilds the officers and crew of the User Groups and Code Camps from some legal situations. It also allows our sponsors to write off the money they send to us for sponsorships as a business expense. Best of all, it makes us look (and feel and behave, believe it or not) like professionals.

In addition, the websites for Richmond User Groups are wholly-owned by the Richmond User Groups Corporation. Remember (from the first post in this series), leaders can flow into and out of leadership. When they leave, the websites are not disrupted – the leaders do not own them, the corporation does.

All that is required when a leader moves away is a change of corporate officer titles. Done and done.

Conclusion

Perhaps incorporating isn’t the way for you to go. Regardless, remember the cool ideas practiced in user groups will work in your corporation. Communities work, people are social (even us geeks!) and want to belong!

:{> Andy

On Developer Communities: You Can Tune A Piano But You Can’t Tuna Fish

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

  1. First, you need a team builder
  2. You can run a company like a user group, but the inverse is not always true.
  3. Quality always works.
  4. People are not resources or assets.
  5. Don’t go away.

Each hypothesis is accompanied by one or more “anti-hypotheses” – clues that you are not participating in a sustainable developer community. 

Every Square Is A Rectangle…

… but not all rectangles are squares. You can run a company like a user group, but the inverse is not always true. You can tune a piano but you can’t tuna fish. What do I mean by all this?

User Groups are big extended communities – almost a family to some members. Meetings are anticipated. Folks even get excited about the newsletter emails! Communication is required, and it must be clear, concise, and consistent.

Just like in corporations.

But there are distinctions to be made. User Groups are nearly always volunteer efforts – even when there is sponsorship money involved. As such, leadership has to exercise patience and maturity when asking things of membership or other leaders. Demands are verboten. Ultimatums are useless. Authority is an honor.

Anti-hypothesis: If leadership wields authority by making demands and delivering ultimatums, you are participating in a dysfunctional community.

Leadership is a privilege.

When there is money involved, the collection and dispersing of finances must be transparent to leadership at a minimum, and should be reported to membership yearly.

More Of Our Story

When we organized the first Richmond Code Camp, companies in the area began asking us about sponsoring User Group meetings. Through sheer serendipity, one company in town pretty much had a lock user group sponsorships. As president of both groups, I now began fielding embarrassing questions about the situation.

At the same time, I wanted to give away cool swag at Code Camps. When I say “cool swag” I mean an X-Box. Although a mediocre salesperson, I could not convince Code Camp contributors to contribute an X-Box. So I began searching for an alternative… “maybe we could buy an X-Box if only we had some money” I thought… (which again reminded me of the Steve Martin shtick mentioned in the first post).

Darrell Norton is an MVP with an MBA from Richmond. If you have a local MVP who has an MBA you already know this: those guys come in handy now and then! Darrell had written a business plan for developer communities years earlier while working in Virginia’s Tidewater region. He circulated it some back then and got at least one taker: a user group from NoVa. It had worked very well for them.

The plan consists of multiple tiers of sponsorship: platinum costs the most but keeps your logo on our website and all communications for a year. Platinum sponsors also get to choose two monthly meetings to sponsor, for which they provide food for the attendees. Gold, Silver, and Bronze levels cost progressively less and offer progressively less to the sponsor.

I approached the company that held the lock on Richmond User Groups and laid out the plan. They had steadfastly supported the developer community for three years. I was going to open up the groups to outside sponsorship using Darrell’s plan, and I would give the company holding the lock three years at the Platinum level for both the Richmond .Net Users Group and the Richmond SQL Server Users Group – free. They agreed.

With our first sponsorship check in late 2006, I formed Richmond User Groups Corporation using LegalZoom. An S-Corporation in the Commonwealth of Virginia, we became a not-for-profit corporation and did not file for charitable status. This preserved the option of selling stuff (sponsorships).

If you plan to follow a similar road, you definitely need to check on the laws in your state, province, and/or nation to see what’s allowed and what isn’t.

The corporation sheilds the officers and crew of the User Groups and Code Camps from some legal situations. It also allows our sponsors to write off the money they send to us for sponsorships as a business expense. Best of all, it makes us look (and feel and behave, believe it or not) like professionals.

In addition, the websites for Richmond User Groups are wholly-owned by the Richmond User Groups Corporation. Remember (from the first post in this series), leaders can flow into and out of leadership. When they leave, the websites are not disrupted – the leaders do not own them, the corporation does.

All that is required when a leader moves away is a change of corporate officer titles. Done and done.

Conclusion

Perhaps incorporating isn’t the way for you to go. Regardless, remember the cool ideas practiced in user groups will work in your corporation. Communities work, people are social (even us geeks!) and want to belong!

:{> Andy

On Developer Communities: The Team Builder

Introduction 

One take-away from the MVP Summit last week is: We’re doing some pretty cool stuff in the Richmond (Virginia) Developer Community. I attended a breakout session on Developer Communities and found the room divided into roughly two groups:

  • Those who were active in a thriving local developer community
  • Those wanted to be active in a thriving local developer community

After participating in the lively session, a couple fellow MVPs gave me their business cards and asked for more information about what we were doing in Richmond. “I need to blog about this” was my first thought. I’m ashamed to admit I don’t know why I haven’t thought of it before. But here goes:

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

  1. First, you need a team builder. 
  2. You can run a company like a user group, but the inverse is not always true.
  3. Quality always works.
  4. People are not resources or assets.
  5. Don’t go away.

Each hypothesis is accompanied by one or more “anti-hypotheses” – clues that you are not participating in a sustainable developer community. 

First, You Need a Team Builder

This reminds me of an old Steve Martin routine (some of you are old enough to recall Steve Martin used to do stand-up comedy…) – “How To Become A Millionaire And Not Pay Taxes” (paraphrased):

First, you need a million dollars. Then when the tax man calls you say “I forgot.”

That first part sounds deceptively simple, doesn’t it? But it’s actually hard work earning a million dollars – or building a team.

In Theory…

A Team Builder is someone with a knack or gift or talent or whatever-you-want-to-call-it for identifying people willing to help along with an area where they can do some good. It isn’t a dictatorship or even remotely authoritarian. Far from it, the Team Builder is usually the quiet one in the back of the room or along the wall in the meeting that makes the one or two suggestions that cut through the Gordian Knot and suggest the solution to everything without raising their voice. It’s up to the group or meeting to realize and acknowledge this is a great idea – and then act upon it.

Anti-hypothesis: If you are currently involved with a developer community where great ideas are ignored for any reason, you are participating in a dysfunctional community.

Team Builders are typically follow-me style leaders, as opposed to go-and-do-that-over-there style leaders. They are actively engaged and mentoring along the way. They get things done initially by doing most of the work, then encourage others to participate and share the workload.

This proves a fantastic model for any type of social instrument. It is not just limited to developer communities. It’s organic. It’s natural. And it just works.

In local Developer Communities, the Team Builder may initiate things by starting a new group. They may participate in the existing organization, they may attempt to participate and be shut out. They may simply wait until the non-organic, unnatural, dictatorship implodes; and then either start helping or rebuild over the debris. Team Builders have a knack for knowing where they’re needed most, and most are extremely patient.

In Practice…

In Richmond, I found myself president of the Richmond .Net Users Group and the Richmond SQL Server Users Group in the summer of 2006. Frank La Vigne and I had restarted the Richmond SQL Server Users Group in May 2006. Although it was a very difficult decision for him, Frank moved to Northern Virginia (we call that area NoVa around here) for better opportunities – personally and professionally.

Frank is a Team Builder. He had started building a team before he left town, and I was part of that team.

Together, Frank and the team were slowly slaying the dragons that held back the Richmond Developer Community. Our Developer Evangelist, G. Andrew Duthie (aka .Net DEvHammer), was a great help getting things going – especially when we decided to put together our first Code Camp in April 2006.

The Key 

The key to all this was finding people willing to step into leadership, assume the responsibility, and remain enthusiastically engaged for as long as possible. Simple right? (First you need a million dollars.)

We accomplished this in Richmond by waiting for folks to walk up and ask “How can I help?” My response is always “What do you want to do?” It usually grows from there – organically, naturally.

We’ve learned we need a minimum of three people in leadership of each group. That allows one person to be sick, on vacation, or out of town and still have a lead and one backup. Each group now has four to six people in leadership. This gives us immense flexibility when it comes to doing additional events – things like last winter’s InstallFest.

More importantly, it allows leaders to flow into and out of leadership. Job responsibilities and life in general can leave someone less amenable to participating in User Group leadership. It’s imperative to not punish leaders for burning out, in my opinion. They burned out doing stuff for the community – let’s not shoot our wounded, let’s allow them ample (personal) time and (personal) space to heal. In fact, let’s build that into the process. Cool?

Conculsion

The Richmond Developer Community is still a work in progress. We’re enjoying more attendance and more active participation – it’s so cool to be part of this community!

:{> Andy

 

On Developer Communities: The Team Builder

Introduction 

One take-away from the MVP Summit last week is: We’re doing some pretty cool stuff in the Richmond (Virginia) Developer Community. I attended a breakout session on Developer Communities and found the room divided into roughly two groups:

  • Those who were active in a thriving local developer community
  • Those wanted to be active in a thriving local developer community

After participating in the lively session, a couple fellow MVPs gave me their business cards and asked for more information about what we were doing in Richmond. “I need to blog about this” was my first thought. I’m ashamed to admit I don’t know why I haven’t thought of it before. But here goes:

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

  1. First, you need a team builder. 
  2. You can run a company like a user group, but the inverse is not always true.
  3. Quality always works.
  4. People are not resources or assets.
  5. Don’t go away.

Each hypothesis is accompanied by one or more “anti-hypotheses” – clues that you are not participating in a sustainable developer community. 

First, You Need a Team Builder

This reminds me of an old Steve Martin routine (some of you are old enough to recall Steve Martin used to do stand-up comedy…) – “How To Become A Millionaire And Not Pay Taxes” (paraphrased):

First, you need a million dollars. Then when the tax man calls you say “I forgot.”

That first part sounds deceptively simple, doesn’t it? But it’s actually hard work earning a million dollars – or building a team.

In Theory…

A Team Builder is someone with a knack or gift or talent or whatever-you-want-to-call-it for identifying people willing to help along with an area where they can do some good. It isn’t a dictatorship or even remotely authoritarian. Far from it, the Team Builder is usually the quiet one in the back of the room or along the wall in the meeting that makes the one or two suggestions that cut through the Gordian Knot and suggest the solution to everything without raising their voice. It’s up to the group or meeting to realize and acknowledge this is a great idea – and then act upon it.

Anti-hypothesis: If you are currently involved with a developer community where great ideas are ignored for any reason, you are participating in a dysfunctional community.

Team Builders are typically follow-me style leaders, as opposed to go-and-do-that-over-there style leaders. They are actively engaged and mentoring along the way. They get things done initially by doing most of the work, then encourage others to participate and share the workload.

This proves a fantastic model for any type of social instrument. It is not just limited to developer communities. It’s organic. It’s natural. And it just works.

In local Developer Communities, the Team Builder may initiate things by starting a new group. They may participate in the existing organization, they may attempt to participate and be shut out. They may simply wait until the non-organic, unnatural, dictatorship implodes; and then either start helping or rebuild over the debris. Team Builders have a knack for knowing where they’re needed most, and most are extremely patient.

In Practice…

In Richmond, I found myself president of the Richmond .Net Users Group and the Richmond SQL Server Users Group in the summer of 2006. Frank La Vigne and I had restarted the Richmond SQL Server Users Group in May 2006. Although it was a very difficult decision for him, Frank moved to Northern Virginia (we call that area NoVa around here) for better opportunities – personally and professionally.

Frank is a Team Builder. He had started building a team before he left town, and I was part of that team.

Together, Frank and the team were slowly slaying the dragons that held back the Richmond Developer Community. Our Developer Evangelist, G. Andrew Duthie (aka .Net DEvHammer), was a great help getting things going – especially when we decided to put together our first Code Camp in April 2006.

The Key 

The key to all this was finding people willing to step into leadership, assume the responsibility, and remain enthusiastically engaged for as long as possible. Simple right? (First you need a million dollars.)

We accomplished this in Richmond by waiting for folks to walk up and ask “How can I help?” My response is always “What do you want to do?” It usually grows from there – organically, naturally.

We’ve learned we need a minimum of three people in leadership of each group. That allows one person to be sick, on vacation, or out of town and still have a lead and one backup. Each group now has four to six people in leadership. This gives us immense flexibility when it comes to doing additional events – things like last winter’s InstallFest.

More importantly, it allows leaders to flow into and out of leadership. Job responsibilities and life in general can leave someone less amenable to participating in User Group leadership. It’s imperative to not punish leaders for burning out, in my opinion. They burned out doing stuff for the community – let’s not shoot our wounded, let’s allow them ample (personal) time and (personal) space to heal. In fact, let’s build that into the process. Cool?

Conculsion

The Richmond Developer Community is still a work in progress. We’re enjoying more attendance and more active participation – it’s so cool to be part of this community!

:{> Andy

 

On Developer Communities: The Team Builder

Introduction 

One take-away from the MVP Summit last week is: We’re doing some pretty cool stuff in the Richmond (Virginia) Developer Community. I attended a breakout session on Developer Communities and found the room divided into roughly two groups:

  • Those who were active in a thriving local developer community
  • Those wanted to be active in a thriving local developer community

After participating in the lively session, a couple fellow MVPs gave me their business cards and asked for more information about what we were doing in Richmond. “I need to blog about this” was my first thought. I’m ashamed to admit I don’t know why I haven’t thought of it before. But here goes:

On Developer Communities… 

I hold the following hypotheses about successful, growing, and thriving developer communities:

  1. First, you need a team builder. 
  2. You can run a company like a user group, but the inverse is not always true.
  3. Quality always works.
  4. People are not resources or assets.
  5. Don’t go away.

Each hypothesis is accompanied by one or more “anti-hypotheses” – clues that you are not participating in a sustainable developer community. 

First, You Need a Team Builder

This reminds me of an old Steve Martin routine (some of you are old enough to recall Steve Martin used to do stand-up comedy…) – “How To Become A Millionaire And Not Pay Taxes” (paraphrased):

First, you need a million dollars. Then when the tax man calls you say “I forgot.”

That first part sounds deceptively simple, doesn’t it? But it’s actually hard work earning a million dollars – or building a team.

In Theory…

A Team Builder is someone with a knack or gift or talent or whatever-you-want-to-call-it for identifying people willing to help along with an area where they can do some good. It isn’t a dictatorship or even remotely authoritarian. Far from it, the Team Builder is usually the quiet one in the back of the room or along the wall in the meeting that makes the one or two suggestions that cut through the Gordian Knot and suggest the solution to everything without raising their voice. It’s up to the group or meeting to realize and acknowledge this is a great idea – and then act upon it.

Anti-hypothesis: If you are currently involved with a developer community where great ideas are ignored for any reason, you are participating in a dysfunctional community.

Team Builders are typically follow-me style leaders, as opposed to go-and-do-that-over-there style leaders. They are actively engaged and mentoring along the way. They get things done initially by doing most of the work, then encourage others to participate and share the workload.

This proves a fantastic model for any type of social instrument. It is not just limited to developer communities. It’s organic. It’s natural. And it just works.

In local Developer Communities, the Team Builder may initiate things by starting a new group. They may participate in the existing organization, they may attempt to participate and be shut out. They may simply wait until the non-organic, unnatural, dictatorship implodes; and then either start helping or rebuild over the debris. Team Builders have a knack for knowing where they’re needed most, and most are extremely patient.

In Practice…

In Richmond, I found myself president of the Richmond .Net Users Group and the Richmond SQL Server Users Group in the summer of 2006. Frank La Vigne and I had restarted the Richmond SQL Server Users Group in May 2006. Although it was a very difficult decision for him, Frank moved to Northern Virginia (we call that area NoVa around here) for better opportunities – personally and professionally.

Frank is a Team Builder. He had started building a team before he left town, and I was part of that team.

Together, Frank and the team were slowly slaying the dragons that held back the Richmond Developer Community. Our Developer Evangelist, G. Andrew Duthie (aka .Net DEvHammer), was a great help getting things going – especially when we decided to put together our first Code Camp in April 2006.

The Key 

The key to all this was finding people willing to step into leadership, assume the responsibility, and remain enthusiastically engaged for as long as possible. Simple right? (First you need a million dollars.)

We accomplished this in Richmond by waiting for folks to walk up and ask “How can I help?” My response is always “What do you want to do?” It usually grows from there – organically, naturally.

We’ve learned we need a minimum of three people in leadership of each group. That allows one person to be sick, on vacation, or out of town and still have a lead and one backup. Each group now has four to six people in leadership. This gives us immense flexibility when it comes to doing additional events – things like last winter’s InstallFest.

More importantly, it allows leaders to flow into and out of leadership. Job responsibilities and life in general can leave someone less amenable to participating in User Group leadership. It’s imperative to not punish leaders for burning out, in my opinion. They burned out doing stuff for the community – let’s not shoot our wounded, let’s allow them ample (personal) time and (personal) space to heal. In fact, let’s build that into the process. Cool?

Conculsion

The Richmond Developer Community is still a work in progress. We’re enjoying more attendance and more active participation – it’s so cool to be part of this community!

:{> Andy

 

Transcript of .Net Rocks Show on Database Testing in CoDe!

The transcript of the first few minutes of the .Net Rocks Show on Database Testing is in the new issue of CoDe Magazine!

Coincidentally, I was presenting on the topic of Database Testing in Roanoke, VA a couple weeks back when the Roanoke Valley .Net User Group received their copies of CoDe Magazine. Robin Edwards (aka Geekette) asked at the end of the meeting “How come you didn’t tell us you’re in CoDe?” I had no idea.

But it’s really cool!

Speaking of CoDe Magazine, I got to meet Markus Egger at the MVP Summit last week – cool guy!

:{> Andy

Dreaming In Code

A month or so back I was perusing MSDN Blogs and followed a link to the Dreaming In Code website.

Buy Dreaming In Code 

I bought it and finished reading the book on my way home from the MVP Summit last week. I recommend it to anyone who wishes to learn more about large software projects.

The book offers a look behind the scenes at the design and development of an open-source Personal Information Manager project named Chandler. Chandler was initially touted as “The Outlook Killer” and the book describes Mitch Kapor‘s frustration with Exchange as one motivation for starting the project.

I found the book a fascinating look into

  • the work that goes into large projects;
  • the team dynamic as applied to software design and development;
  • open source development.

The book is slightly biased towards open source development and the open source community, but it’s subject is an open source development project so the bias is expected. That shouldn’t prevent anyone from reading the book. The challenges and pitfalls of producing great software bear no respect for platform or language. 

One of the points the author drives home is how little we as developers and IT professionals study our own field. If you read my ramblings, you are probably not in that crowd.

The book’s conclusion (and several reviews) led me to believe the project is a failure. I disagree – I don’t think it’s finished yet. Some things take time. Good software sometimes – often, in fact – takes more time than anyone can foresee at the start.

:{> Andy

Dreaming In Code

A month or so back I was perusing MSDN Blogs and followed a link to the Dreaming In Code website.

Buy Dreaming In Code 

I bought it and finished reading the book on my way home from the MVP Summit last week. I recommend it to anyone who wishes to learn more about large software projects.

The book offers a look behind the scenes at the design and development of an open-source Personal Information Manager project named Chandler. Chandler was initially touted as “The Outlook Killer” and the book describes Mitch Kapor‘s frustration with Exchange as one motivation for starting the project.

I found the book a fascinating look into

  • the work that goes into large projects;
  • the team dynamic as applied to software design and development;
  • open source development.

The book is slightly biased towards open source development and the open source community, but it’s subject is an open source development project so the bias is expected. That shouldn’t prevent anyone from reading the book. The challenges and pitfalls of producing great software bear no respect for platform or language. 

One of the points the author drives home is how little we as developers and IT professionals study our own field. If you read my ramblings, you are probably not in that crowd.

The book’s conclusion (and several reviews) led me to believe the project is a failure. I disagree – I don’t think it’s finished yet. Some things take time. Good software sometimes – often, in fact – takes more time than anyone can foresee at the start.

:{> Andy

Dreaming In Code

A month or so back I was perusing MSDN Blogs and followed a link to the Dreaming In Code website.

Buy Dreaming In Code 

I bought it and finished reading the book on my way home from the MVP Summit last week. I recommend it to anyone who wishes to learn more about large software projects.

The book offers a look behind the scenes at the design and development of an open-source Personal Information Manager project named Chandler. Chandler was initially touted as “The Outlook Killer” and the book describes Mitch Kapor‘s frustration with Exchange as one motivation for starting the project.

I found the book a fascinating look into

  • the work that goes into large projects;
  • the team dynamic as applied to software design and development;
  • open source development.

The book is slightly biased towards open source development and the open source community, but it’s subject is an open source development project so the bias is expected. That shouldn’t prevent anyone from reading the book. The challenges and pitfalls of producing great software bear no respect for platform or language. 

One of the points the author drives home is how little we as developers and IT professionals study our own field. If you read my ramblings, you are probably not in that crowd.

The book’s conclusion (and several reviews) led me to believe the project is a failure. I disagree – I don’t think it’s finished yet. Some things take time. Good software sometimes – often, in fact – takes more time than anyone can foresee at the start.

:{> Andy

Customer Feedback

On the MVP Summit… 

Later today Christy and I leave Seattle. Our trek to my first MVP Summit was our first trip alone since Stevie Ray was born – and Stevie Ray turned five in February.

We won’t wait that long again. We had fun! 🙂

Since this was my first MVP Summit I’m not sure how it compares with previous years. There was a lot of activity. There was the usual cool stuff that we cannot talk about without violating the Non-Disclosure Agreements (NDAs) MVPs must sign in order to participate in Summit sessions, but it will be public knowledge soon enough. There were also live addresses by Ray Ozzie and Steve Ballmer, followed by Q&A with the attendees, which were both informative and entertaining.

What struck me most was the openness of the Microsoft Dev Teams in seeking our feedback.

I spent most of my feedback time with the SSIS Team and found them very interested in what SSIS developers had to say. I was admittedly skeptical when they initially told us they wanted our honest feedback, but they convinced me as I watched them interact with us individually and as a group – they literally kept at us until we dropped the pleasantries and told them the things they wanted to learn from us. The group included lots of people I admire in this industry; names you would recognize if you do ETL work or use SSIS at all; folks whose blogs and books help us all (sometimes daily!). I describe this group as a collection of very intelligent SSIS developers… plus me.

The exchange of information worked both ways. I have one large pet peeve about the product cycle (that I will not further define here). I was able to learn why things are the way they are, and it made sense to me.

This is indicative of my Why-in-the-world-did-they-do-it-like-this experiences using Microsoft products over the past couple decades: There was a reason. Critics will argue this reason is inferiority. Critics need to read the definition of “de facto standard,” marketshare reports, and The Art of War (although I kind of hope they don’t read either and continue blindly criticizing what they do not understand).

On Software Companies… 

Microsoft, it turns out, is a software company after all.

So is Andy Leonard Technology, Inc.

Does Microsoft always get things right? No. Do I? No. Does either company make excuses? No – we improve it and move on.

Microsoft is not immune from the “gotchas” that plague our industry, they are simply criticized in proportion to their size in the industry. Since they are large, they are criticized heavily. From what I saw and heard this week, they respond to the criticism with the same vigor as they respond to the challenges of writing software that delights customers.

When attendees shared complaints and issues with the software, I did not see a “Crap! I was hoping no one would ever uncover that!” response. Instead, I saw a “Crap! How did we miss that in testing?” response.

In response to competition I witnessed acknowledgment, brutal honesty, and even humor.

For me, it was reaffirming. 

On the SSIS Team… 

Kudos to the SSIS Team for their work! Kudos for involving a lot of the people I admire in this field in discussions on their product and for inviting us to share what we really thought.

I depart Seattle believing the next version of SSIS will be better, faster, stronger. I leave with informed confidence in this team. I go with more friends than I had upon arrival.

:{> Andy