Disclaimer: This post represents my own views of alt.net and is merely an expression of what I would like to see it become. This is not necessarily the view shared by anyone else. I do not speak for this group.

So this alt.net thing has been around for almost a year now (as a named concept anyway), and with the upcoming Seattle event, I've been wondering what my place in this world is, what my contribution can be, and most importantly, what my passion in software is, and how I can work toward it. I want to go to Seattle next month and have something to say, something I believe in, and not just be an observer. The following is a quick dump of my thoughts on the subject.

Thus far my exposure to alt.net has been through various mailing lists, twitter, and blogs by community members. I have virtually met a lot of smart people and great developers through this, but the direction, when it exists, is split. A common goal and purpose seems elusive. Often discussions surrounding alt.net either devolve into the purse fight type of discussion, or filter into a "how can I use/why is [NHibernate, Rhino Mocks, NUnit, Castle] better than [some thing I do RAD|The Microsoft Way]"

Had I my druthers, I would love to see alt.net evolve into a community practicing a variety of (I hesitate to use "best practices" but alternative terms escape me) methodologies with a variety of tools aimed at doing software well, and doing it right, and more importantly, teaching that philosophy, and teaching those practices.

I will forgo the use of labels that may be seen as derisive and divisive, and state my observation from my career that developers fall into two very broad camps: those who at least lurk but maybe participate in "community" activities (blogs, conferences, mailing lists, etc) and those who, for whatever reason, do not. I will call the former Group A, and the latter Group B. Group A may or may not be doing things right. They may or may not be up on the latest tools or methods, but they are out there trying to learn. Group B, contrary to popular may still be out there trying to learn. Those guys just do it primarily through books, magazines, Google, the MSDN library, and their immediate coworkers. Just because a developer hasn't plugged into a community does not mean he doesn't care.

I feel like alt.net, in some part, can be a group that is willing to stand in the gap between Groups A and B and find ways to deliver the right messages to Group B. Developer B may work with one or more Developer A's. We have an opportunity to not just educate A at a code-camp or in a blog post, but help him further educate B, and educate the pointy-haired boss as well. There was talk at one time of alt.net books, and while some thought the idea laughable, the truth is, Group B developers buy books, maybe they have a book budget, and they do what the books say. This is a way to touch non-community-involved developers. Jeremy Miller has made a step in the right direction I believe by publishing an alt.net editorial in MSDN magazine. Lots of Group B types get MSDN magazine. It comes free with MSDN Subscription. Companies that employ Group B types also hire consultants. The consultants can be bringing the message and making sure they are leaving the place better than they found it, not just from a code standpoint, but from a knowledge and understanding standpoint as well. The point is, Group B can be reached if we are willing to find a way and work for it. The question becomes, I guess, is it worth the effort? I say it is. All boats rise with the tide, and if we can force ourselves (not just alt.net mind you, but all Group A types) out of the cabin and into stowage once in a while (it's a funny analogy don't crucify me) then we should see a rise in the industry as a whole.

Alt.net is partially about tools, with good reason. There are good and bad tools out there. There are a lot of great tools that are open source or not "endorsed" by Microsoft that aren't being used simply out of fear. However, talking about tools is not enough. Pushing and IoC container on a developer if he doesn't understand the need it fills and how it fills it is as bad as Microsoft pushing Enterprise Library. I say pushing not because MS made the statement "Thou shalt use EntLib" but because by putting it out their they gave it the de facto endorsement as "the Microsoft Way". How many shops are using EntLib where it is unnecessary, or using it incorrectly, because they were not properly educated on the underlying principles? The tools are a means to an end. But before choosing a means (or an end for that matter), we should be making sure developers are making educated choices.

We need to be teaching people to fish, and moreover, making sure they have the tools to teach the rest of their tribe to fish. There was talk about a "street kit" of sorts aimed (I believe) at this purpose, and I hope to see that come to fruition. But it can't just be about teaching the tools. It has to be about teaching the concepts. To that end, we should be working with each other to make sure everyone is on the same playbook, that we are presenting a unified, educated front when taking the message to the masses. If five different people present TDD you will come away with five different understandings of the why, but a good idea of how to set up a test harness. This is unacceptable. It's an incomplete education, and it leads to misuse and abuse and later abandonment of a good practice. One of the things that David Laribee and others wanted to see happen was the idea of "peer review" for material relating to software development. Sadly, this seems to come up as the exception rather than the rule, at least in the public forums, and as a result we are potentially doing a disservice to the consumers of the information we present in blogs, conferences, and code camps. If we truly want to see software move closer to science and engineering as a discipline then we should be equally disciplined in our research and publishing.

We can't ignore the complexity of a real-world developer's work situation. Jacob Burkhardt said "The essence of tyranny is the denial of complexity." I think that is completely appropriate in this context. I have seen too many conversations about "how do I adopt [x] when my manager/client/stakeholder/team members don't understand it" yield no practical information about how to work with this complexity of environment. Not everyone is out there writing software commercially or as a hired-gun, making their own rules, and working for people that also understand software. Getting buy-in on something as simple as TDD is a non-trivial problem in many IT shops. To that end, I feel like alt.net can do some work to create real, tangible evidence of why the practices we preach are the right practices, why they work better than alternatives, and how to be flexible and still implement them in spirit, or incrementally, to gain the buy-in of those who may be in charge. We need case studies and testimonials that give concrete evidence of how well these practices work. Anecdotal evidence isn't enough.

It's been said that people want to eventually remove the "alt" from alt.net.  I find this to be a powerful goal, but it won't happen, in my estimation, until we are willing to stand in that gap and find a way to bring these practices in a uniform, demonstrable, repeatable way to the masses that exist beyond the glass walls of the alt.net community.

And that's why I'm in the game.

Guys I would love to hear feedback. Am I living in an ideal dream world thinking this goal is achievable? Am I wrong to even think it's that important? I just want to open up some discussions.