Scott Hansleman just wrote a piece describing a conversation with DHH and Martin Fowler and then moves on to talk about ALT.NET as follows (lifted from the post):

What does it mean to be to be ALT.NET? In short it signifies:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principals and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principals [sic] (e.g. Resharper.)

So I read this and I'm just thinking "of course that's what you do".

Perhaps I've been lucky in that most developers I've worked with don't have strong feelings one way or another other than the drive to do a good job.

My previous development team was almost entirely Microsoft (with a few additional packages and some specialist proprietary software) and as such pretty much all of the development work was .NET (predominantly ASP.NET). To that end, we'd look to use best practices described by Microsoft but the point was that this is not without question: the smart guys in the team were encouraged to find better ways of doing things. Take a look at Mark's blog - a key architect in that team - and you can see that he is certainly considering other approaches all of the time although day to day he's working inside a series of agreed parameters and technologies.

The decision to change approach, or embrace a community best practice required common sense and judgement balancing a number of factors. Consider:

• We need to get things done as efficiently and effectively as possible.
• We need to minimise risk to the business.
• We need to be sure that technology is "here to stay" (in as far as one can) and will be supportable.
• We need to ensure that the entire team can work with the concepts.

And there a probably other factors too that present themselves circumstantially. So a good 'for instance' is the adoption of NHibernate. Makes sense in lots of ways: it's well respected with a good community from a proven concept, it fills the need to use an O/RM for sophisticated modeling and speeds up development time. But it met with some resistance at the time because some developers found it hard to learn etc. So the question was: is it a step too far? In this case NHibernate won because it represented decreased risk over individual (or even group) development of frameworks to do the same thing.

It's about judgement and common sense at the time against a set of guiding principles. Frankly, I'd be unlikely to trust a developer who worked in any other way.

Next, it's about revisiting those decisions, and the principles behind them to make sure they still hold true in the face of changing technology and changing contexts. So you've embraced 'agile' practices? Good for you. Now don't be smug - challenge it, make it work better and check that it ever worked in the first place. And then do it again.

Heed advice that's out there and learn from existing practices. But always, always question what, why and how.