Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: Re: Re: Production Environments and "Foreign" Code

by janx (Monk)
on Mar 12, 2003 at 23:12 UTC ( #242533=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Production Environments and "Foreign" Code
in thread Production Environments and "Foreign" Code

We're using Perl 5.004.04 (which I know is full of bugs and some quite serious security holes anyway).

You do what? No, seriously. I think there's something wrong with that attitude.
I'm not arguing the usefulness of evaluation of software to be used in production - by no means.

But this seems reckless to me. On the other hand, very probably your codebase actually relies on those bugs in external software (I've seen that oh so often ... :-( ), and if it does upgrading would be disastrous, indeed. But consider: How many people actually know the trouble spots in 5.004.04 and know how to avoid pitfalls. Is the primary reason to distrust outside code a missing test suite which ensures the robustness of your system?

Is your staff actually a good enough team to tackle XML parsing on its own without taking years to do it right. Without hiding disastrous bugs in that code? And if they are good enough, wouldn't they be good enough to do proper code review on existing modules and feeding those bug fixes back to the community, serving others as you perfect your system?

I know from personal experience that we employed external code (CPAN modules in this case) which contained bugs. We found them in our testing environment, fixed them and sent patches to the author.
In other cases we looked into modules which supposedly did what we needed, but simply weren't usable. So we wrote ourselves.

Ergo: By using external code, you don't have to use all external code there is. Which means: You can still write your own if you want/need to. Careful selection of modules is of course necessary as some others have noted above, too.


  • Comment on Re: Re: Re: Production Environments and "Foreign" Code

Replies are listed 'Best First'.
Re^4: Production Environments and "Foreign" Code
by adrianh (Chancellor) on Mar 13, 2003 at 10:03 UTC
    You do what? No, seriously. I think there's something wrong with that attitude. I'm not arguing the usefulness of evaluation of software to be used in production - by no means.

    It's not always a bad approach to make. An environment with a large number of known bugs (which you can work around) can be better that an environment with unknown bugs - even if there are less of them.

    The cost of staying with a known system can be larger than the cost of migrating and discovering all those new bugs.

    Of course the cost of standing still increases with time as the rest of the world moves on.

      True enough.

      I'm just in the trouble spot of turning such a legacy system into state of the art object oriented system, so that we can finally get rid of our prehistoric database layout.
      This system has been in use for over 5 years now and been maintained (or rather mutilated) by programmers with very varying degrees of sophistication.

      So I'm very aware of having to rely on existing bugs :-(


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://242533]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (2)
As of 2023-03-28 17:26 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (68 votes). Check out past polls.