Discuss: Not Invented Here Syndrome

Posts   
 
    
Posts: 22
Joined: 11-Jan-2008
# Posted on: 18-Jan-2008 11:29:44   

I have raised this issue already but i would like you to share also links here that discusses NIH . I think we are one of the commercial entities who are weighing the productivity benefits and impact on the product on using tools like LLBLGen. We would like that we can have the flexibility to deploy neat assemblies and even LLBGen ORMSupport classes will just appear as ours in some way simple_smile .

One more, i would like to give your opinion on the issue that we may inherit the bugs and issues that will be raised by llblgen if other developers tried to use our product. To give everyone an idea, we are developing a complete suite of ecommerce solution both webforms and winforms. there will be an exposed business platform/api where other developers can extend the application or customize it. Point given, using llblgen will increase the learning curve of extending the application as they have to study the architecture and how llblgen does things.

TIA.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 18-Jan-2008 11:49:13   

It's a matter of costs. If a team thinks it can write a data-access solution with fine grained rich functionality in, say a month, they should do it. I don't think that's possible, but lets say they manage it. Say the team contains 4 people. That's a 4 man-month project. What are the costs for such a project? I bet it's higher than 229 euro's wink

That's also the thing with other libraries one might use. No-one writes their own grid, one picks one off the shelve. This is for the same reason: the time to write one, debug it and maintain it are far higher than the purchase price of a 3rd party version. Even if you add the learning curve, which is actually not that important, considering that own-made libraries also have a learning curve, unless they're used by the same person who wrote the library.

Frans Bouma | Lead developer LLBLGen Pro
luciusism
User
Posts: 119
Joined: 02-Jun-2007
# Posted on: 07-Mar-2008 07:49:30   

Otis wrote:

It's a matter of costs. If a team thinks it can write a data-access solution with fine grained rich functionality in, say a month, they should do it. I don't think that's possible, but lets say they manage it. Say the team contains 4 people. That's a 4 man-month project. What are the costs for such a project? I bet it's higher than 229 euro's wink

Don't you mean 229 * 4? simple_smile

I'd agree w/ Fran's comments 100%. A classic case of comparative advantage. (Wow, I'm pulling out Ricardo from econ 101simple_smile Unless you think you're going to build a better DAL solution, and/or you feel that that is where the value of your solution will lie, then you'd probably want to roll your own. If you think the value of your solution will be higher up, then why not let a product such as LL handle the lower level stuff?

Besides the features, one of the biggest reason we chose LL was that we we already set on using asp.net (so no Hibernate or Rails) and of all the .net ORMs, LL was the most popular and seemed to have the strongest community. (I guess it helps that Frans never sleepswink )