The thing about .NET - as well as virtually every other Microsoft platform - is that there's One Way To Do Things, which is described in MSDN and various books, and that's how most MS shops do it. For .NET in particular, this meant datasets not long ago. Now, the tide is turning - unit testing is promoted more and more, EF2 comes with POCO support, ASP.NET MVC specifically lists TDD as design rationale, and so on. It's already at the tipping point: my wife works in a .NET shop where most of the code is written just as you describe. Their next project is going to be done using ASP.NET MVC and L2S, with unit tests all the way. Why? Because Microsoft says it's the Next Big Thing.

With that in mind, you might want to stick around for a little longer, and see how that works out.

You don't need the majority of jobs - you only need one.

If you can't change your company, change your company!

I think that the technologies you espouse are a great way to approach software development but from my own experience I feel that they're seen as an "Ivory Tower" in most development groups. I do agree that .NET shops are probably more likely to not follow best practices (again from my experience) but going Java will be no panacea. Deadline is king everywhere you'll go and most shops will skip past "Ivory Tower" ideals in hopes of meeting a deadline.

P.S. You're fairly new to SO. If you keep reading the posts here for a while you'll see that MS shops are definitely coming around to best practices development by the kinds of questions that are being asked and answered on a daily basis.

Also, there's a competitive challenge to MS from the open source community. For instance, I'm fairly sure that ASP.NET MVC was created by MS as a direct competitor to Ruby on Rails development, and that's a good thing. It will force the issue with a lot of shops. E.g. You have to do MVC to do ASP.NET MVC. You can't put biz logic into your UI, it's just not practical.

This is why I like small shops. If you're a big fish in a small pond you can become a catalyst for change. It's much harder to do this with an army of developers and tons of bureaucracy in the way. This isn't a technology issue, it's the culture of the company that's the problem.

I used to work at a company that was very deadline centric. Whichever client was screaming the most would be top priority and it would result in compromise in code quality and design. This would happen every day resulting in a gigantic mess of unmaintainable code, builds that were not usable, and numerous other problems. A few of us at the old company tried our hardest to inject some of the design patterns you mentioned but it would always result in arguments with the lead developers saying it couldn't work, how can this fit our needs, what about time frames, and the best one yet, "If this causes me more work, you should watch out for your job" After many months of tring we realized that company was a lost cause and I decided to go elsewhere.

Like another commenter mentioned finding a new development shop or a small group can really help get some of these ideas in the main line from the beginning. At my new job I am trying to really push these ideals to help out the company as a whole and i am slowly winning them over. With Team City, Nunit, NCover, and a slew of other tools. Trying to get the people to work smarter not harder. It is an up hill battle but finding the right company is the best thing where you can feel that you are rewarded at the end of the day.

Places are out there just need to not jump ship immediately to another platform just because you think the grass is greener on the other side.

Good Luck!

The killer in my experience is that you learn on the cool tools: NHibernate and NUnit but then have to professionally work with the tools that are a poor substitute: EF and MSTest 2005.

This makes me a sad panda.

I'm at a company who uses .NET as the main platform. The project I'm developing is one where we are using C#, Silverlight, NHibernate, Spring, and SQL Server. I think it is a matter of the company you are with. If you have the ability to change the culture then go for it.

There is probably a higher percentage of Java shops which practice/value these skills due to the fact that these ideas have had much longer to bake in the java community, because Java developers are more likely to have had experience with older OO-technologies (C++, Smalltalk, etc.) and because many of the pioneers, thought leaders, and everyday aspiring software craftsman developing in the 90's and early 2000's migrated to the Java platform and haven't seen the .Net platform offer a compelling enough reason to change.

That said, the .Net community is starting to mature, and those who have a firm foundation in good software development practices will have an advantage as these ideas continue to take hold and will have nothing but an increasing number of opportunities to work with those of like mind as time goes on.

Be patient, and be the change :)

The same thing can be done with Java or any other language. I've heard of a large (1000's of employees) company using Oracle stored procedures for pretty much ALL of their business logic, period. The thought of writing this, not to mention maintaining and testing it, gives me a headache. The only use for Java and other languages there is for simple clients that just read and write to a huge set of stored procedures.

I think changing to Java or some other platform because of a view that they "do it right" is risky. ie The grass is always greener. As someone with similar experiences, I am definitely sticking with .NET.

I'm tipping that, in many Java shops, the application of good design, testing and development approaches didn't just happen magically. It was probably initiated by an experienced architect or developer just like you (or me) who had the experience to be able to see beyond the current project.

It does appear that the Java culture in general seems to encourage a focus on good design and testing as well as coding. However there is no technical reason why these same focuses can't be applied to .NET projects.

Non technical reasons such as culture and deadlines definitely cause problems, however Java projects suffer from exactly the same problems. Cultural issues in Java shops are often at the other extreme can occur (i.e. "never use stored procedures" even when they are the best choice).

That's not to say making change is easy. But I think having good a relationship with management, demonstrating by example, and basic perseverance are probably the most important factors in helping to improve the situation.

From a career perspective, it is completely reasonable to leave a company that just doesn't value your experience or ability to see the bigger picture, regardless of the technologies used. There are of course many practical considerations (i.e. having another job to go to) but with some companies, if you feel this way, you're far better off moving on.

If what you want to do is short-term contracting, you need to learn the buggiest and most unproductive tools in wide use, as the teams using those approaches will be the ones hiring short-term contractors to fix their problems.

On the other hand, maybe what you want is a long-term, high-commitment, job. Then switching languages while using the same design approach is probably less of an overhead than vice-versa. A shop that says 'you look like a good software engineer - knowing C#, you can pick up Java/Python in a month' is one you can see spending several years working for.

Three shops in a row and six years of "Nhibernate, OOP, Design Patterns, Domain Driven Design, Test Driven Development, IoC, MVC" :-)

Welcome to Scandinavia (Malmö/København) ;-)

Unless you are coming in as the architect of the project you are on, I agree, there is very little use for technologies that are not accepted by the team, or are seen as unnecessary confusions.

That being said, use the technologies you want for your own projects, or start an open source project, that way you can get real experience on the tools you like, ready for when you get the opportunity to make these decisions.

And, rest assured, there are companies that use these technologies.