Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Reusing code is good; reinvention might be better

by jlongino (Parson)
on Sep 24, 2001 at 19:58 UTC ( #114351=perlmeditation: print w/replies, xml ) Need Help??

I realize that this is not directly Perl related but I've seen the topic bounce around several times in both the CB and SOPW. I enjoyed reading the following article by Peter Coffee, and thought that others here in the monastery might enjoy it as well. He makes some good points, although I'm sure it applies more to advanced programmers rather than newbies (but then they stand to gain much from the experience if nothing else).

I asked for his permission to include the entire text of his article, since there is no direct URL to it and it is distributed via e-mail newsletter. Here is his response:

Subject: It's not my copyright, but...
Date: Fri, 21 Sep 2001 18:33:10 -0400

If you include the hyperlink for subscribing to the newsletter, I can't imagine my publisher having a problem with your sharing the (attributed) content. Thanks for asking.

- Peter

So here is the link to subscribe, as per his request: eNewsletters from Ziff Davis Media and here is the article, enjoy!:


-- By Peter Coffee --

Have you ever heard someone use the phrase, "reinventing the wheel," in a positive sense? In my experience, no one likes the idea: the implication is always either (1) "we didn't know we could have just cloned that" or (2) "these people were either too proud, or too stupid, to use what was already working."

In the case of software development, though, I wonder if there's something to be said for starting over from time to time, instead of falling victim to viral programming: that is, to the rapid spread of the first solution good enough to work at all.

Sorting algorithms are perhaps the canonical example: There are so many of them, and the good ones all trend toward the same limit of O(n log n) performance for a list of n items, but their performance in specific situations (partially ordered input list, for example) can vary greatly. Some require much more memory than others; some lend themselves to parallel-processing environments; some can approach O(n) performance if you know enough about the data going in (see link below).

If you think, "Well, we have a sort routine in the library," you can cripple an application's performance. Some wheels are worth reinventing.

Software defect trend analysis, for example in the reports produced by Reasoning Inc.'s automated source code inspection tools (see link below), has sometimes found odd concentrations of similar errors in long-lived projects. When the history of those errors is traced, it sometimes turns out that copying and pasting from an early source code module has proliferated a subtle conceptual error throughout other code. When code is going to be reused, it needs to be evaluated at least for correctness, but better still for whether it's good enough to reuse instead of reinventing.

Critics of the C and C++ programming languages have been known to apply the "viral" description to their rapid spread and continued popularity: The first compiler written for a new platform, they opine, will be used to write its first decent operating system and will become the lingua franca for its mainstream applications, even if other languages (whose compilers take longer to port) might have yielded higher productivity in writing more reliable code--if only people had been willing to wait a little longer to get started. (See links below.)

The next time someone asks, "Are we reinventing the wheel here?" don't assume that you must prove you are not. "The wheel we have now is square," may be the more appropriate response.

"Experience is not what happens to you. It is what you do with what happens to you." -- Aldous Huxley

  • Comment on Reusing code is good; reinvention might be better

Replies are listed 'Best First'.
Be elitist - reinvent the bad stuff!
by dragonchild (Archbishop) on Sep 24, 2001 at 20:27 UTC
    Hear, hear! ++!!

    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 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 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.

A third option
by CubicSpline (Friar) on Sep 24, 2001 at 21:17 UTC
    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.

      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".


Understanding *IS* Better
by chromatic (Archbishop) on Sep 25, 2001 at 00:45 UTC
    People who don't understand existing code are doomed to reimplement it badly.

    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.)

Re: Reusing code is good; reinvention might be better
by idnopheq (Chaplain) on Sep 24, 2001 at 21:54 UTC
    Ah, yes! Back in Best way to fix a broken but functional program? I posed something similar. The jist of the responses was to "redo the damn thing"! As I did. Time proved that rebuilding it was far easier than undersanding not only the style of the code but the bit of history in which it was writen.

    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.

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

Re: Reusing code is good; reinvention might be better
by stefp (Vicar) on Sep 24, 2001 at 22:33 UTC
    Reinventing the wheel or at least making the first few step of doing so is a good and necessary exercise. It makes for a better apreciation of the strength and weakness of existing wheels. Eventually one uses existing wheels with more confidence. Also it is good to provide feeback to "wheel reinventers". More than "you should use such and such". If too obvious for the average perlmonks, it can be carried by private messaging.

    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

Re: Reusing code is good; reinvention might be better
by lemming (Priest) on Sep 24, 2001 at 21:13 UTC

    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.

Re: Reusing code is good; reinvention might be better
by John M. Dlugosz (Monsignor) on Sep 25, 2001 at 10:21 UTC
    A long time ago (early 90's) I was invited to do a piece for Ed Yordon's rag, American Programmer. The issue was about code reuse. Just to be contrary, I wrote about "The Case for Starting Over" and went into the software ageing process. The overall design and implementation can handle some kinds of changes, but not others.

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


Re: Reusing code is good; reinvention might be better
by Dinosaur (Beadle) on Sep 25, 2001 at 22:36 UTC
    Good post, good discussion. But you didn't include Coffee's "links below". They look interesting; can you publish them? Tx, D.
      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

by t13 (Novice) on Sep 27, 2001 at 03:27 UTC
    When reinventing, I also like to retain the original version for sanity checking. This way you always have the option of switching between the new and old to see if a bug is particular to one or the other. This of course isn't always feasible or worthwhile... (Usually this is most useful when trying different numerical algorithms.)


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://114351]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2017-06-25 11:29 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (567 votes). Check out past polls.