I would like to make a subtle distinction between reinventing square wheels and reinventing almost-round wheels. For example, a huge number of posts in SOPW are from people who are trying to duplicate CGI.pm or similarly exhaustively-tested modules. Don't reinvent those wheels unless you have to!

Instead, be intelligent about what it is you're using. Don't blindly use something just because it's there. Instead, if you're going to put something in your application, be selective! Be elitist! Just because everyone else is using it isn't a good enough reason.

I use CGI.pm in my production code because it's good, not cause everyone else says to. I would try it out in a development area because people on PM say to, but I wouldn't immediately throw it into production.

You should use that logic with everything you didn't personally write or have a hand in designing. Don't be a lemming!

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

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.

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

I find it hard to believe any *working* code is bad enough that it can't be refactored. (Maybe Netscape 4. Maybe.) If the code has been maintained at all, it's had bugfixes and tweaks. Any reinvention will need much luck to avoid making the same mistakes.

I certainly wouldn't throw out anything longer than a day's work (say, 100 lines of Perl). If it's not an optimal solution for the specific case, generalize it enough that you can provide the choice for next time. If the code's not good enough for reuse, fix it so it is.

Otherwise, you'll probably run into many of the same traps as the first time.

(I'm not discouraging people from learning. I'm not discouraging alternate solutions. I'm just saying, throwing out working code and starting over from scratch is the last option in my book.)

Pits and bieces of it I was able to cannibilize, sure. But in rewriting it I became very familliar in what it was doing and how, and made it more stable and smaller than it was before.

As with anything like this, look at the thing before you ditch it all together. USD $0.02.

HTH
--
idnopheq
Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.

~ Shunryu Suzuki

And our nodes in the monastery are redactional wheels too. They may rehash what have been said before over and over. It may appear like a work of Sysiphus. It is not.

And my Englih will eventually improve if you msg me my mistakes :)

-- stefp

Most of the time when we see the wheel answer is when some newbie is struggling with code that could be done with a module call. If you are going to reinvent code, we expect to see some experience and that you looked at the relevant module.

wtf?

So there are objective criteria you can use to decide if a module/project/function should be rewritten or modified.

—John

I glad that so many people have enjoyed this article. Out of the 10 or so e-mail newsletters I subscribe to, I would have to say that his (Peter Coffee) is the one I like best.

In addition to the links you've requested from the original post, there is also an online article Calling the wizards to war of his that was fun.

• To read more about sorting algorithms, click here
• To read more about Reasoning Inc.'s automated source code inspection tools, click here
• To read a critique of C++, click here
• To read more about C++, click here

• To e-mail thanks to eWEEK Technology Editor Peter Coffee, click Peter Coffee
Honest, I'm not on the eWeek payroll!

"Thank you for sending me a copy of your book - I'll waste no time reading it." -- Moses Hadas

t.