If there’s one thing that everyone in software development can agree on, it’s that everyone has an opinion on what the best way is to do things. We have lots of books, blogs and articles touting “best practices” and telling us how to do things (and how not to do things).

Often times as a consultant, you are brought into an IT shop where the native developers aren’t using the latest and greatest technology and might not be using the so-called “best practices” that you subscribe to. Usually in these situations, the people that brought you in are bringing you in for your expertise and are expecting you to do things the right way. This can lead to the native developers feeling somewhat threatened.

Recently a friend of mine started at a new client and noticed that the developers there were do most of their data access through dynamic SQL written in their C# code. When he questioned why they did it that way, the developers got defensive, saying things like, “We’ve been doing it that way for years and it’s been working for us.”

While the “best practices” would not recommend you doing all of your data access this way, it dawned on me, this guy is exactly right. He’s been writing his dynamic SQL for years, and he’s been succeeding in delivering working software. So in his mind, he’s not doing anything wrong.

There are two ways of handling this situation. The one that many people choose it to rip on the guy for being so stupid for ever thinking of doing it that way, while saying things like, “No one does it that way anymore”. All this does is alienate the developer and turn them off from trying to learn something new.

The preferred method is to show them that there is a better way. I once asked Andy Hunt how to get people who don’t write unit tests to start writing unit tests. His answer was that I needed to show them what was in it for them. I don’t think he could’ve been more correct. No one wants to do something just because it’s a “best practice” or some smart person said you should do it that way. We’ve all worked with people or seen projects where some “smart” person made something way more complicated than it needed to be and no one else could understand what they did or how to write code using their framework. No one cares if those people used “best practices”, you just hate having to come to work and deal with the mess that they made.

So if you’re working with someone and you think that there is a better way than how they’re doing something, show them the better way. Acknowledge the fact that what they are doing is working for them (they probably wouldn’t be doing it if it wasn’t). Just don’t belittle them for doing it that way, because they may be doing the best that they can.

Ever since Microsoft announced that the Entity Framework was their ORM of choice, people everywhere have been saying, “LINQ to SQL is dead!” A lot of people feel like they’re not allowed to use LINQ to SQL anymore and that they have to use Entity Framework instead.

In fact, LINQ to SQL is not only alive and well, Microsoft has even announced LINQ to SQL improvements in .NET 4.0, including finally adding using ITable<T> for tables instead of Table<T>, which makes it much easier to test. Combine that with this open source tool that will create an IDataContext interface for you and you’re on your way to testable LINQ to SQL. So no, LINQ to SQL is not dead!!

Look, just because Microsoft says you should do something a certain way doesn’t mean that you have to do everything that they say. For example, Microsoft will almost never recommend using an open source software package over something that they’ve built (I say almost never because I’m sure they’ve done it at some point, but I’ve never seen it done). That certainly doesn’t mean that the Microsoft product is better than every open source tool.

For example, if you’re going to use an ORM, LINQ to SQL can get the job done for you, but if you’re looking for an ORM with more features, you owe it to yourself to check out Fluent NHibernate.