Issues to consider when choosing data access technologies?

Question

There were times when we had to choose between 2 or 3 technologies/strategies to develop modules.

Now for every small or large component/module/project, we have almost uncountable options. It might be easy for those with years of experience, but not for those who are new to programming, say less than a year.

I get frustrated sometimes with the choices out there for data access in the .NET world. We cannot go and read about every tool there is in the market and what it has to offer, for each and every product.

The reason for coming up with the question is recently we had to work on a project and specs for the DataAccessLayer were finalized with ADO.NET. About 20% of the way into the project, a new developer joined our department (but not our team). I'd consider him smart, helpful, and we enjoy working with him.

During a code review, he personally advised us that it was better to use LINQ to SQL for the module we were working on. He was convincing. After a positive debate, we agreed to use LINQ to SQL.

However, the "management" was not happy about that. There argument was that we should have come up with this "fantastic idea" before starting the module. Their argument is that resources have been spent on 20% of the work so far, and that work will be wasted.

Given the pace of new products/technologies/strategies coming out frequently, we find it difficult to have all information about all these tools and technologies.

We've had success using ADO.NET. We had an idea about LINQ (in general), NHibrnate and many others, but we went ahead ADO.NET. I am not opposing learning new things, that is the reason we collectively pushed for using LINQ.

Question Are we at fault for making this choice at the time we did?

Are there any metrics or guidelines for making a decision about which to technology choose for certain situations, and when not to switch mid-stream?

Answer 1

Time frame, and project risk. Those are the fundamentals.

I am not familiar in any depth with LINQ or ADO.NET, but that's not important.

At a high level, I can see no difference between LINQ and ADO.NET. I can see LINQ being "better", "more elegant", less code and clearer. But, in truth those are not big project risks if the team is already familiar and comfortable with ADO.NET. You're still going to get your data in and out of the database, and the team already knows how to deal with the "less elegant, more code, less clear" ADO.NET (mind these are generalizations, not judgements per se).

If there's time in the project to be able to absorb the adoption of something like LINQ, and it's demonstrably better even for a new technology, then I can see adopting it for new work, and perhaps retrofitting it in old, done work.

If you have, like, a year long project, its easy to see where there could easily be enough "slack" in the timeline to adopt a new technology. If it's a 1 month project, perhaps not so much.

While there are many wonderful new techs out there, and they are coming out every day, much can be said about wrangling "the devil you know" vs adopting something new and unproven. This is why, personally, I do most of this kind of exploration on my time, at home, in "hobby mode" so that I can be better informed for new projects when a new tech might be suitable and appropriate over our tried and true "old school" methods.

Otherwise, time needs to be made available during project specification to proof new tech to determine its appropriateness for inclusion at project start. Many times, folks making specifications aren't given that time.

Answer 2

It's a challenging, and increasingly more difficult, task to keep all of the current technologies in mind when starting a new project.

I try to always follow whatever is the cutting edge, so that I know what is out there. This is a matter of reading a lot of blogs, attending conferences, and staying current.

That being said, you don't want to always use whatever is on the cutting edge. My rule of thumb is to estimate the ship date of the product. I try to use whatever technology will be the newest to have received at least one "service pack" or update by the date we're going to ship. Granted, this involves a lot of guesswork, since ship dates aren't known, but experience (in watching the industry) helps tremendously.

There's an art to making educated guesses about which technologies will be popular, and which will fall away over time. Unfortunately, that's really a matter of experience. If you have a developer with many years of experience who also stays up to date with current technologies (important), then they are a good resource to help in this decision making.