What is the order of topics to explain to a .NET developer or user group to get them started and interested with alt.net tools and practices.
ALT.NET is more of an attitude than a set of tools and practices.
I don't know that you can "get someone started with ALT.NET," per se.
To me it is an attitude born of experience, not something you can put on like a coat. But that is my opinion, subject to change.
The essential principles to drive home are:
Then, after version control (!), I'd start with continuous integration, and show how getting immediate feedback on the quality of a build can help improve quality from the first moment. Doing CI first doesn't change the codebase.
Then I'd introduce automated end-to-end testing of the application with FitNesse, Watin or somesuch. This should then illustrate how refactoring code isn't something to be afraid of if you have good testing tools that will verify that the code still works.
Then I'd do gentle refactoring to break out business logic and domain objects from the UI (if they're not there already) and introduce unit testing. This further shows how refactoring is a good thing.
As we aim to get some sort of seperation of concerns, design patterns (such as IoC) will naturally start to become apparent. It's also going to be obvious that we can replace the data layer with ORM.
As we refactor, I'd also show how test-driven development can actually speed creation of better code. This is probably easiest shown for the first time with new development, as otherwise it's quite a culture shock!
I don't mean becoming an ALT.NETter just in a way of letting them know that the stuff are out there but in a way that they can understand it and feel that it can help them.
I think it depends on the individual or group. Almost all shops have some exposure to one of these concepts. From there, I would introduce new concepts only as fast as you think the developer or team can absorb them. It's quite depressing to see teams start rejecting some of the important principles and concepts because they are over-loaded. And try not to assume someone understands the principles behind using CI, IoC, or mocking frameworks.
I think a lot of people don't know about Generics, delegates, Linq and Lambda expressions.
If you will tell then all at about the same time then they will just drop everything.
Like you wouldn't teach a beginner programmer whats a DSL but you can let him know about SVN.
The Alt.NET Podcast may be a good place to get some ideas. They have podcasts on continuous improvement, agile, DI/IoC, ORM, OOP w/ Ruby, etc. (in that order).
For me it was a colleague who championed IoC/DI and TDD. He also got me going to .net user groups so I could see that he wasn't just a one-off crazy guy who loved using new and strange technologies for the sake of using them.