views:

340

answers:

13

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.

+13  A: 
  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

John Saunders
Some good points. However, if your existing framework meets your needs AND you have a decent training process in place to get new developers familiarized with your custom framework I don't think it's always better to change. Some of the frameworks have a lot of features (bloat) that you may not ever use.
TLiebe
"bloat" only matters if it affects you. I doubt the Linq framework adds enough bytes to the EXE to matter one way or another. And it's *highly* unlikely that the Microsoft frameworks are more bloated in the sense of resource consumption (memory, etc.) than someone's in house solution. Having a feature you don't need is only a problem when that feature gets in the way of something you do need, or when you are paying an additional cost for that feature.
Russell Steen
"Bloat" is a nonsense reason. If you don't use a feature, then it doesn't matter that it's there, at least not with a well-designed framework. What percentage of the .NET Framework do you use? And why waste time training on your framework when devs are already trained on the Microsoft framework?
John Saunders
@John: "bloat" is an *excellent* reason not to use a framework. Features that are frequently used at least have the advantage of being well-tested in the real world, regardless of how badly written they are. Features that are rarely if ever used are like little ticking time-bombs, just waiting for a new developer to come along and use them, thinking they're going to work as advertised.
MusiGenesis
@MusiGenesis: you're assuming that a company like Microsoft doesn't test the rarely-used features as well as the frequently-used features. Bad assumption. Note also that I said, "a well-designed framework". That leaves out frameworks with feature creep problems.
John Saunders
@John: does code that hasn't been changed in 16 years sound like "a well-designed framework" to you? I think your argument is of course perfectly valid when applied to Microsoft stuff, but if I was forced by circumstances to use the software equivalent of Guns-n-Roses, I wouldn't touch anything that wasn't already being used heavily.
MusiGenesis
@MusiGenesis: Read more carefully, and see my comments to the question. I'm way against his old framework, and it's certainly not the one I was referring to. I was referring to EF or just about any other serious ORM framework.
John Saunders
@John: you're right, sorry. I read everything *but* TLiebe's first comment.
MusiGenesis
+9  A: 

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.

Sohnee
This is what I was going to say.
ChrisF
But having built CompanyXORM in isolation will have moved you on to Master status, young padawan.
Eric Smith
+4  A: 

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.

Nelson Reis
A: 

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?

olle
+2  A: 

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.

Rui Craveiro
+1  A: 

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

David in Dakota
A: 

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.

MusiGenesis
BS! How can you think that my framework will remain as is for 16 years (i.e. no update would take place on the source code)?
JMSA
@JMSA: Is your framework object-oriented? Does it take into consideration the lessons learned in the last 16 years? If so, then you should sell that framework - you'd make a lot of money.
John Saunders
@JMSA: I can't actually say if your framework is any good, having never seen it. However, 1993 was a very very very long time ago, and much has changed since then, not only in the way in which code is written, but also in the environments in which the code is running. I actually can't believe that you're running source code that hasn't been changed *at all* in 16 years.
MusiGenesis
@MusiGenesis: Even if the source has been well-maintained, the _design_ is more likely the issue. It was designed for 16 years ago. That's **10 generations** ago in computer terms (wrt Moore's law).
John Saunders
+4  A: 

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.

Developer Art
+1  A: 

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.

Dev er dev
A: 

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.

Nader Shirazie
+2  A: 

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.

P.K
+2  A: 

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.

Nelson Reis
A: 

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

Scott Weinstein