Arved Sandstrom wrote, quoted or indirectly quoted someone who said :
re-inventing the wheel.
Yes. The problems is very few programmers also possess the skill to
document their packages. Much of the time you waste more time trying
to decode their documentation and perform tests to find out what the
code really does, and trying to persuade the author a bug exists and
that he should fix it than you would spend writing a specialized
"wheel" which you understand perfectly.
For small "wheels" reinventing in embarrassing often the more
efficient technique.
On the other hand I worked at NIH (Not Invented Here) places where
EVERYTHING gets reinvented needlessly. Programmers tend to grossly
underestimate how much work is involved in creating and maintaining a
wheel.
Sun's contribution was the definition of various APIs like JavaMail
and JDBC that others could implement. You afford to invest time in
learning the API, and you know that if you vendor goes belly up, you
can pretty well just plug in another.
Any time you use somebody else's code, you are to some degree handing
them your testicles on a plate. They can go out of business, drop the
project, start charging exorbitantly for it, fill it with bugs, add
some onerous licence condition...
Any time you create your own wheel, the author himself may understand
it perfectly, but usually it will not be documented as well as a third
party product, so the project becomes dependent on that author's
continued employment.
Especially in large bureaucracies, buying third party software is
perceived as prohibitively expensive because of the hassle of the
acquisition paperwork. Reinventing is then falsely perceived as free.
Perhaps we need some guidelines on when and how to pick good
premanufactured wheels and when to reinvent the wheel.
ular implementations thereof. Furthermore the learning curve is a good inv=
estment as the skills will travel with you.