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
From: peter_coffee@ziffdavis.com
To: jlongino@jaguar1.usouthal.edu
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!:
REUSING CODE IS GOOD; REINVENTION MIGHT BE BETTER
-- 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
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 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. | [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
|
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] [Watch: Dir/Any] |
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.) | [reply] [Watch: Dir/Any] |
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.
HTH
--
idnopheq
Apply yourself to new problems without preparation, develop confidence in your ability to to meet situations as they arrise.
| [reply] [Watch: Dir/Any] |
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 | [reply] [Watch: Dir/Any] |
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.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
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.
—John | [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
Permutations.
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.)
t. | [reply] [Watch: Dir/Any] |
|
|