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/