If we have developed our own ORM framework and the framework is working fine over the years then why should we learn and use brand new .net technologies like LINQ or Entity Framework or NHibernate or CSLA.NET for our upcoming software projects?
Note : New frameworks need new effort to learn and teach.
Note : This is just an analogy.
BTW, "LINQ", per se, is a technology complementary to your framework
Because what you currently have is proprietary and unknown... and you want to still be able to develop your code efficiently if you get new staff.
There's nothing wrong with writing your own ORM, but maybe Entity Framework 2 contains some stuff you didn't think about - and there's a whole team and community behind it making it better all the time while your code just gets stale (I'm not saying it is, by the way - it's just an example).
From a personal point of view, knowing nHibernate is a transferable skill. Knowing CompanyXORM isn't.
In my opinion, you should, at least, check those new technologies and compare them to the ones that you developed.
Make a list of pros and cons of the new technologies compared to what you have, and decide what's better to use in your next projects.
However, if your framework is 16 years old, you really should take care because at this point it will hold you back in a number of situations you will find in new projects.
I can think of a couple of reasons.
so looking at these arguments I think you need to turn the question arround and say. What does my technology have over these others, is it worth it? is it perhaps something you could add to the publich technologies?
Hi, there are loads of advantages in using existing frameworks. - Knowledge. Everyone who you invite to work with your framework will have to learn it. On the other hand, there are loads of people knowing how to work with EF, NHibernate, etc.
Knowledge. You find loads of information, tips, how-tos, books, videos, etc., about existing frameworks. If want to have those materials for your framework, you have the cost of creating them.
Knowledge. Try asking a question about your own framework in StackOverflow. The odds of getting an answer are very slim.
Evolution. NHibernate and EF are constantly evolving. The cost of evolving your own framework is all yours and you don't get to share it with other companies... unless, of course, you are selling licenses for it and competing against EF, NHibernate, etc.
Bugs. This is related to the previous. You have to fix your own bugs, instead of simply reporting them.
Agility. This is the biggest of them all. Is your framework as easy to use and as fast to develop as something that uses linq. It is very hard to build something as well thought as linq has been.
Language integration. Microsoft has the advantage of defining the language so it adapts to the frameworks. For Linq, C# evolved dramatically. Without those evolutions, Linq wouldn't even exist.
The only advantage in keeping your own framework is that you control it. This is a very false sensation of security as you control the framework, but still don't control what you have built it upon. There is a false sense of security in staying in the comfort zone.
Of course there is some pain in changing but sometimes rather than implementing or maintaining a buggy implementation of something that exists, it's a stronger long term strategy to get something that has a sole focus on whatever the problem domain is.
With respect to the specific domain of data access, if you are not using LINQ/ADO.NET Data Services/ORM you will find compelling reasons in several areas:
Support for a RESTful API for access to your database which prevents you from implementing lots of contracts and operations in your services.
LINQ queries are very powerful for manipulating data without roundtripping.
Moving away from a stored procedure model of data access.
Frameworks/Platforms coming out are designed to work well with these technologies. For example, LINQ goes quite well with WPF/Silverlight since you deal with a lot of IEnumerable collections of your Plain Old C# Objects / Data Transfer Objects.
These are just a few reasons but there are a lot more. Community has been a big reason that I've liked using out of house projects - either the Microsoft ecosystem if you choose Entity Framework or the very vibrant open source community around projects like NHibernate.
Although I do feel as though a lot of the people who work on these projects are smarter than me, for the moment assuming that I'm as smart as they are the issue that remains is that they spend enormous amounts of time living within that specific problem domain whereas I have other problems that my customers need me to focus on. By letting John Smart or Jane Intelligent focus on ORM, I can spend more time on the business related problems (which, "oh yeah," is my job).
If your in-house framework is, as you say, 16 years old, you should dump it faster than Anne Hathaway dumped her Ponzi-scheme-running Italian boyfriend. It just can't be any good, sorry to say.
We have exactly your kind of situation where I work. We have a custom ORM framework built up since times of .NET 1.1.
We have been gradually accepting new technologies. Why?
Because the .NET framework now offers out of the box whatever was created with significant effort. It would only benefit to throw out a big chunk of legacy code in favor of a few API calls.
New bounties like LINQ, extensions methods, lambdas etc. greatly improve the productivity of work and help in streamlining the code. No reason whatsoever to ignore them.
If you're thinking of other ORMs, let me tell you that a great number of very qualified people have worked on them, and they likely have made it better than you.
If you hire new people, it is easier to get them productive as soon as possible, if you built upon the common framework. Otherwise you will get a long setback until they have learned your framework.
If you're not using the latest bells and whistles, many interesting people will not work for you. Or, if you manage to trick them into singing up, you may not be able to hold them for long.
Just because your new employer will not care much about your knowledge of some proprietary internal framework. He will ask for LINQ or whatever is widespread industry standard at that point it time.
In many cases, writing your own implementation of ORM/CodeGen/Workflow/Other allows you to be very sensitive to the needs of your application. You can customise your implementation to fully satisfy all requirements, and evolve it as requirements change.
On the other hand, it is yet more code that you are responsible for maintaining, testing and debugging. If there are third party implementations that also meet your requirements, then it is useful to consider them, since it reduces the maintenance burden on your team. Additionally, it will continue to evolve and improve because it is the third party developer's primary responsibility. There may be new features and approaches incorporated into the product that you find useful, or couldn't think of, or just couldn't justify spending the time to implement. On top of that, the amount of investment you have to make in training new people goes down, since there's more material available, and more likelihood that they are already familiar with the technology.
But let me stress -- do what makes sense to you. If your current ORM is working well, there's no need to change. When it does come time to make changes to the ORM, then it'll be useful to consider whether its worth just switching over to something else, as long as it meets your requirements.
The key here is how much time and effort do you put in every year to maintain this 16 year old framework. You should evaluate other frameworks to see if they match your specific needs and how much direct/indirect costs will this take in short & long term.
Another thing you should consider:
cost vs. benefit
How much is costing you to:
Another cost would be the technical debt you should have: I imagine you really should have a great one by now.
All these costs (or a big chunk) could be reduced using a new framework.
The benefits you can have from your current framework shouldn't keep up with the costs you are having with it.
Because other developers will hate using it, and resent you for for making them use it.