On Jan 4, 2008 2:10 AM, Michael S. [email protected] wrote:
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.
For instance, authentication. The perl library we used to do this has
an extreme amount of configurability, and it end up being very hard to
debug when we have problems. Rewriting the major part of this took us
under an hour, resolving the problem and making things easy to handle
and debug. It used to take us several hours to debug every error; the
rewrite was actually part of a single authentication debugging
session.
Another instance is the session library. It is a complex mess of
spaghetti, due to solving a bunch of problems we don’t need solved,
and a direct implementation should be about 40 to 100 lines of code
(probably closer to 40). Alas, we’ve not dared replace it, since
since it is used all over the place over many hundreds of thousands of
lines of code, and some subtle issue could crop up and be nasty. If
we’d just written the code when we first needed sessions, we wouldn’t
be in this mess.
An external solution very seldom satisfies the following requirements:
- Totally seamless upgrades and integration along with the rest of the
project - Having somebody local that completely understands the code
- Having it be the minimal amount of code necessary to handle your
requirements - Follows your coding standards
In addition, with an external library you get extra olution search
costs (finding the library), evaluation costs, integration/setup
costs, and potentially debugging costs at later points - in addition
to costs from not fitting the above soft requirements.
You should use external libraries when the benefit from the library
exceeds these costs. You should use a locally written solution when
the costs of using something external exceeds the benefit.
I personally like to erri on the side of writing locally rather than
on the side of adding too many dependencies, as I find that I tend to
underestimate the particular amount of grief from an external
dependency more than I underestimate development time, and that
particularly in aggregate external dependencies give grief at more
random times when I need things to get easy.
Eivind.
