A third option

jlongino++ for a deep meditation (for software developers, especially)!

I'd like to add in my two cents in the form of a third alternative. Often times the code that is out there that attempts to achieve your goals may be close, but not quite up to your standards, or it might not meet 10% of your needs. Rather than sighing and deciding you need to recreate that library/module/source it may be worthwhile to spend time and resources refactoring the existing code.

Give a developer time to get a good understanding of how the existing code works and to diagnose it's shortcomings and what needs to be added to make the code valuable enough to use. A small amount of time is all that's necessary to make a decision, taking into account the time&resource cost of starting from scratch vs the cost of reworking what has already been built.

Certainly refactoring existing software has its drawbacks, having to work with someone else's code being one of the big ones, but it can definitely save time and resources that could otherwise be spent more judiciously.

Comment on A third option

Replies are listed 'Best First'.
Re: A third option by John M. Dlugosz (Monsignor) on Sep 25, 2001 at 10:28 UTC
I work on software for medical imaging applications. So they take quality a bit more seriously than most shrink-wrap software vendors. I developed a set of standards for evaluating outside software and vetting it for use in our code. It includes the possibility of wrapping it with extensions to make it play nice with global names etc., and "quality extensions" to make it less brittle or handle errors better or things like that. It also has a lot to do with documentation and correct use. For example, STL containers and iterators are neat, but they are like pointers in terms of their danger and should be used "internally". —John	[reply]

Replies are listed 'Best First'.

Re: A third option
by John M. Dlugosz (Monsignor) on Sep 25, 2001 at 10:28 UTC

I developed a set of standards for evaluating outside software and vetting it for use in our code. It includes the possibility of wrapping it with extensions to make it play nice with global names etc., and "quality extensions" to make it less brittle or handle errors better or things like that.

It also has a lot to do with documentation and correct use. For example, STL containers and iterators are neat, but they are like pointers in terms of their danger and should be used "internally".

—John

[reply]