In-house Frameworks vs New C# Technologies

Question

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.

Answer 1

I just come along this even it is pretty old question.

Well if you have framework which worked for a long time and you think it is really good you probably don't need to switch to a new technology unless you clearly see that the new technology brings you advantage and solve some pains you have with your current framework. Frameworks simply become obsolete over time so unless you put very big effort to maintain your framework you will move forward one day.

As rule of thumb - create proof of concept with another framework so that you can compare real behavior.

From the other side:

I worked in company where some group of developers (supported by global company policy) thought that their framework is better then publicly available ones. I have never feel such frustration when using API which was wrong, hard to use, buggy and totally undocumented. The result was this question. Yes and I left that company.

Edit:

I noticed that your framework was 16 years old?! I hope you made a change - even .NET is not so old so it should show you how many things have changed. Unless you work in mainframe environment (you don't because you are using .NET) where stuff lives for a long time you must simply move forward every few years.

Answer 2

Because other developers will hate using it, and resent you for for making them use it.

Answer 3

Another thing you should consider:
cost vs. benefit

How much is costing you to:

• maintain your framework, smashing bugs, improving performance, etc.
• develop new features
• train your current staff for improvements and in-house best practices
• train new developers that never saw your framework

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.

Answer 4

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.

Answer 5

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.

Answer 6

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:

1. Support for a RESTful API for access to your database which prevents you from implementing lots of contracts and operations in your services.

2. LINQ queries are very powerful for manipulating data without roundtripping.

3. Moving away from a stored procedure model of data access.

4. 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).

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

I can think of a couple of reasons.

• LINQ will benefit you in many ways (doing all kinds of different tasks) and isn't mutually exclusive. linq 2 sql is a different storry
• There probally is more knowledge and guidance available on these public technologies then on your framework
• Other pieces of technology might be made to intergrate nicely with these publicly available technologies where you have to do the work for your framework
• If the customer ever needs to switch shops they will have an easier time (that is more a benefit of the customer then you but I do think it's your duty to think of this)
• it will be easier to recruit new employees who already know these public technologies. Chances will be you won't find someone who knows yours. So ramp up time for new people can be much less.

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?

Answer 13

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.

Answer 14

1. Because new developers will know the newer frameworks, but not yours
2. So you don't have to waste time maintaining code that Microsoft would maintain for you

BTW, "LINQ", per se, is a technology complementary to your framework