Maintaining third party libraries becomes exponentially easier when you know and intimately understand how they work (usually by at least building a basic prototype of a similar solution). --Jeremy On Jan 4, 2008 10:05 AM, Francis Cianfrocca <garbagecat10 / gmail.com> wrote: > On Jan 4, 2008 8:54 AM, Eivind Eklund <eeklund / gmail.com> wrote: > > > On Jan 4, 2008 2:10 AM, Michael Schuerig <michael / schuerig.de> wrote: > > > On Friday 04 January 2008, Jay Levitt wrote: > > > > The very same arguments people use about "write your own > > > > authentication system so you know what it does" can be extrapolated > > > > to "write your own framework" - and, from there, to "write your own > > > > language", "build your own computer", and "don't believe anything you > > > > haven't seen with your own eyes". It's all of a piece. > > > > > > I'd consider it bad advice to tell people to "write your own X so you > > > know what it does." It encourages people to ignore work that has > > > already been done and particularly ignore the thinking that has gone > > > into that work already. What's the point of having your homebrew X that > > > you fully understand, but that is broken-as-designed? Write your own X > > > if you understand the existing alternatives and they can't be made to > > > do what you need. > > > > My opinion: You often cannot do this evaluation until you have written > > your own or have been badly bitten by existing alternatives. For > > instance, in the web application framework I work in (which is written > > by one of the guys I work with and modified quite a bit by me) we have > > a few external dependencies, and they bring us an inordinate amount of > > grief. > > > > > There's a great deal of merit in both points of view. But there may be a > basic architectural consideration at work here too. > > It's axiomatically a good thing to leverage the good thinking (and > debugging) done by others. Any number of Unix heavyweights have made the > point about "standing on the shoulders of giants." > > But the task of debugging and maintaining a production-quality piece of code > is correlated strongly with its size and even more with its heterogeneity. > Adding in a lot of external libraries, no matter how well designed and > executed, is going to create problems simply by virtue of the number of > points of contact. > > But I don't necessarily think the whole answer is to develop local solutions > to standard problems. For really standard pieces of basic functionality, > tightly-focused small external libraries are usually the right answer. (You > probably won't roll your own XML parser, for example.) But sbove that level, > things get very fuzzy, very fast. > > The world still hasn't found a really good solution for creating > loosely-coupled applications that can leverage external functionality > without incorporating it in-process. And there are many reasons for this: > impedance mismatches, performance problems, lack of integration standards, > and many others we've discussed many times already. > > The enterprise world, which has strong economic motivations to solve this > problem, is finally creeping tentatively toward a commitment to SOAs, after > talking about it for years. The problem in this space is that the discussion > has been driven by vendors, who all want to control the network standards > used for loose-coupling. But none of the standards (XML-RPC, SOAP, REST, > many others) is really ideal. As a result, people have been focusing on all > the wrong things, and there is a lot of home-grown mish-mash out there. > > We're still years away from a real solution. > -- http://www.jeremymcanally.com/ My books: Ruby in Practice http://www.manning.com/mcanally/ My free Ruby e-book http://www.humblelittlerubybook.com/ My blogs: http://www.mrneighborly.com/ http://www.rubyinpractice.com/