in reply to Re:(2501- further clarification) Implementing strict on shoddy code
in thread Implementing strict on shoddy code

If your management does have half a point. If the code isn't broken, why fix it? From the standpoint of making development cycles count, cleaning up working code isn't a good move, at least not on the surface.

So, wait until you do need to fix it. As soon as any maintenance is done on one of the scripts, the "exit criteria" include use strict;

If, over time, the code will get "cycled" (I assume you mean "recycled") then make use strict; a criteria for any new code. The people on the team who haven't gotten the religion will get their chance then.

patience is the magic formula here.

Replies are listed 'Best First'.
Re: Re: Re:(2501- further clarification) Implementing strict on shoddy code
by extremely (Priest) on Feb 10, 2001 at 11:26 UTC
    If the code isn't broken, why fix it?...
    Because there are two kinds of broken, "not working now" and "waiting in the bushes for you". Just because it works doesn't mean it isn't broken. It just means that you can't see how it is going to fail right when you need it the most.

    One of my earliest big perl scripts was an ISP signup form. It wasn't broken at all until some jerk wanted a "$" in his friggin' login name. =) And then, it was horribly, horribly broke...

    --
    $you = new YOU;
    honk() if $you->love(perl)

[reply]
      I'd have to go with extremely here.

      It is something I have never truly understood but the basic fact is that things will tend, in the course of time, to go tits-up: Call is the second law of thermodynamics, call it bit-rot, blame it on Bill Gates; whatever - Systems that once worked well can for no readily apparent reason stop working.

      Of course, there is always a reason: It just isn't immediately obvious. The problem is that when you start working on sufficiently large and complex systems - such as something like a bunch of CGI scripts running off a database, so not terribly large - silly little things in the code can cause what was once a nice system to stop being so happy.

      Example: If your code is run as a cron-job, for example, and does something like file-archiving or logging and it hits a snag you might not notice until, three weeks and several hundred/thousand/hundred-thousand log entries later when you really need something urgently. Then you notice that those last three weeks your script has been appending just so much garbage to your nicely comma-delimited file.

      While I don't really mean what I have written in the title (except for publicly available CGI, where paranoia isn't the problem, it is a lack thereof) for business applications you have to write and maintain in a defensive manner.

      Elgon

[reply]
      Another "been there" to extremely
      My first big Perl project was fairly complicated and then I went to other things. I had left some code in that didn't do anything but generate a lot of data. The data interpretor wasn't done. There were other parts that were badly designed, etc...
      The person that took over me, didn't do anything to the code and forbid his co-worker to touch it.
      I wound up back in that area. Ouch. Nothing worse than looking at your old code. It still ran, but some of the parsing wasn't happening correctly and some errors were happenning, but they were stealth errors.
      Sometimes it just looks like it's running.
[reply]

In Section Seekers of Perl Wisdom