Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > crisis Perl

Reply
Thread Tools

crisis Perl

 
 
cartercc
Guest
Posts: n/a
 
      10-15-2008
Over the past four years, I've written a fair amount of Perl. Some of
it has been 'crisis Perl'. This results in scripts that solve a
problem but are thrown together in a hurry with inefficient, untested,
and confusing code. When the crisis resolved, I wanted to go back, do
real testing, and rewrite the script, but have been told on almost
every occasion to leave it alone. The fact that it seemed to worked
was good enough, and most of this code found its way into production.

In the past month or so, I've had to look at four scripts I have
written this way. One script was over two years old, and the newest
was several months old. Needless to say, dealing with confusing,
uncommented, and inefficient code is a problem! It would have been
much easier to clean up the code when it was written than to rewrite
it months after the fact.

I actually knew better than to not clean up the code, but it was
easier at the time not to pick a fight with my managers. This isn't an
excuse, but an explanation.

How do you deal with a manager who tells you to leave a script alone,
when you know good and well that it's such poorly written code that it
will be extremely hard to maintain, and perhaps will be buggy as well?
Getting another job isn't an option, and firing the manager isn't an
option, either.

CC
 
Reply With Quote
 
 
 
 
Josef Moellers
Guest
Posts: n/a
 
      10-15-2008
cartercc wrote:

> How do you deal with a manager who tells you to leave a script alone,
> when you know good and well that it's such poorly written code that it
> will be extremely hard to maintain, and perhaps will be buggy as well?
> Getting another job isn't an option, and firing the manager isn't an
> option, either.


Just give it to him in writing. If you later get into trouble, at least
you told him before! Maybe one day he'll listen.

Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html
 
Reply With Quote
 
 
 
 
Ted Zlatanov
Guest
Posts: n/a
 
      10-15-2008
On Wed, 15 Oct 2008 06:53:09 -0700 (PDT) cartercc <(E-Mail Removed)> wrote:

c> How do you deal with a manager who tells you to leave a script alone,
c> when you know good and well that it's such poorly written code that it
c> will be extremely hard to maintain, and perhaps will be buggy as well?
c> Getting another job isn't an option, and firing the manager isn't an
c> option, either.

This is why you should not write poor, unclear code even in a crisis.
The real problem happened during the crisis, when you compromised the
quality of your work. The situation now was inevitable after the choice
you made back then.

The best you can do is build a convincing case for the necessity of a
rewrite. Focus on the bugs in the code, not its beauty. It will make
you look bad, though, since it was your code anyhow.

Next time, don't give in to the pressure of "do it now." Besides the
consequences you see above, it's also a great way to get into an even
deeper crisis if you write buggy code in haste.

Ted
 
Reply With Quote
 
Andrew DeFaria
Guest
Posts: n/a
 
      10-15-2008
cartercc wrote:
> I actually knew better than to not clean up the code, but it was
> easier at the time not to pick a fight with my managers. This isn't an
> excuse, but an explanation.

You should start telling your manager that you don't have the time to do
it over so you're gonna take the time to do it right in the first place!
> How do you deal with a manager who tells you to leave a script alone,
> when you know good and well that it's such poorly written code that
> it will be extremely hard to maintain,

The quick answer is that you don't. You just fix the code. Your manager
is not charged with maintaining your code so it's not his problem - it's
your problem! You don't ask your manager for time to tidy your desk -
it's your desk and you care for it as you see fit.
> Getting another job isn't an option,

Getting another job is *always* an option.
> and firing the manager isn't an option, either.

Getting another job *is* firing the manager - hell the whole company!
--
Andrew DeFaria <http://defaria.com>
Read my chips: No new upgrades!

 
Reply With Quote
 
RedGrittyBrick
Guest
Posts: n/a
 
      10-15-2008

cartercc wrote:
> Over the past four years, I've written a fair amount of Perl. Some of
> it has been 'crisis Perl'. This results in scripts that solve a
> problem but are thrown together in a hurry with inefficient, untested,
> and confusing code. When the crisis resolved, I wanted to go back, do
> real testing, and rewrite the script,
>
> How do you deal with a manager who tells you to leave a script alone,
> when you know good and well that it's such poorly written code that it
> will be extremely hard to maintain, and perhaps will be buggy as well?
> Getting another job isn't an option, and firing the manager isn't an
> option, either.


Firstly, I'd try to practice Perl more frequently so that when a crisis
occurs, I am better able to write good Perl under pressure.

Secondly, I'd make it my aim, that in a crisis, I'd stay calm, take my
time, and attempt to write clear well-documented Perl from the start.
This is, of course, much easier said than done. However, I think that if
you make this a goal and remind yourself of it regularly, then you are
more likely to be able to achieve a result closer to your goal.

If the above is achievable then your aims won't come into conflict with
those of your manager and there won't be a problem.

It's also worth bearing in mind that your manager probably has
legitimate concerns that you don't. For example he or she might have a
budgetary or priority driven need to avoid spending resources polishing
something that is already operational and performing adequately. I'd
find out what my managers concerns were, then go away and think about
other ways those concerns might be addressed. Then you might be able to
propose some approach that meets both your concerns. At the end of the
day though, the manager has the duty and authority to manage. You have
to accept that.

Just my ¤0.02 worth.

--
RGB
 
Reply With Quote
 
sln@netherlands.com
Guest
Posts: n/a
 
      10-15-2008
On Wed, 15 Oct 2008 06:53:09 -0700 (PDT), cartercc <(E-Mail Removed)> wrote:

>Over the past four years, I've written a fair amount of Perl. Some of
>it has been 'crisis Perl'. This results in scripts that solve a
>problem but are thrown together in a hurry with inefficient, untested,
>and confusing code. When the crisis resolved, I wanted to go back, do
>real testing, and rewrite the script, but have been told on almost
>every occasion to leave it alone. The fact that it seemed to worked
>was good enough, and most of this code found its way into production.
>
>In the past month or so, I've had to look at four scripts I have
>written this way. One script was over two years old, and the newest
>was several months old. Needless to say, dealing with confusing,
>uncommented, and inefficient code is a problem! It would have been
>much easier to clean up the code when it was written than to rewrite
>it months after the fact.
>
>I actually knew better than to not clean up the code, but it was
>easier at the time not to pick a fight with my managers. This isn't an
>excuse, but an explanation.
>
>How do you deal with a manager who tells you to leave a script alone,
>when you know good and well that it's such poorly written code that it
>will be extremely hard to maintain, and perhaps will be buggy as well?
>Getting another job isn't an option, and firing the manager isn't an
>option, either.
>
>CC


First, I just want to tell you, none of the other replies to your
post you should even consider. Not even the one recommending you
write better code or learn from your mistakes.

You should not mention, nor try to coerce any response from your
manager, concerning the desire to redo something you know you could
do better the second time around, whatsover!

If your manager contacts you about a bug that comes up with your
legacy code, act shocked, don't say anything at all, look at the
code, find the bug and fix it... AND NOTHING ELSE !!!
Don't try to rewrite sections that look shabby or any crap like that.

Fix it, test it, then LET IT GO man! Give the impression to your
manager the code is otherwise perfect.

Remember, if your company does validation, you don't wan't to change
anything unless you have to after its been in production. To do so
would risk getting fired, and I'm sure you don't wan't that.

If your code falls under the umbrella of an overhaul, then by all means,
if you have the time, redo as much as you feel comfortable with.
But remember, it will have to be validated again.

I won't mean jack to your company how much you 'clean up' old code,
they only care about money ....

sln



 
Reply With Quote
 
xahlee@gmail.com
Guest
Posts: n/a
 
      10-16-2008
On Oct 15, 6:53 am, cartercc <(E-Mail Removed)> wrote:
> Over the past four years, I've written a fair amount of Perl. Some of
> it has been 'crisis Perl'. This results in scripts that solve a
> problem but are thrown together in a hurry with inefficient, untested,
> and confusing code. When the crisis resolved, I wanted to go back, do
> real testing, and rewrite the script, but have been told on almost
> every occasion to leave it alone. The fact that it seemed to worked
> was good enough, and most of this code found its way into production.
>
> In the past month or so, I've had to look at four scripts I have
> written this way. One script was over two years old, and the newest
> was several months old. Needless to say, dealing with confusing,
> uncommented, and inefficient code is a problem! It would have been
> much easier to clean up the code when it was written than to rewrite
> it months after the fact.
>
> I actually knew better than to not clean up the code, but it was
> easier at the time not to pick a fight with my managers. This isn't an
> excuse, but an explanation.
>
> How do you deal with a manager who tells you to leave a script alone,
> when you know good and well that it's such poorly written code that it
> will be extremely hard to maintain, and perhaps will be buggy as well?
> Getting another job isn't an option, and firing the manager isn't an
> option, either.


in general, that's how real word code works. In my experience, almost
all production code are like that. Live with it.

The time when your desire to rewrite is appreciated, is when things
broke or things need change. When that happens, they will come to you
first, or you may have already moved on.

Maybe one day you'll become a manager, and you'll probably make the
same choice.

Xah
∑ http://xahlee.org/

☄
 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      10-16-2008
>>>>> "cc" == cartercc <(E-Mail Removed)> writes:

cc> How do you deal with a manager who tells you to leave a script
cc> alone, when you know good and well that it's such poorly written
cc> code that it will be extremely hard to maintain, and perhaps
cc> will be buggy as well? Getting another job isn't an option, and
cc> firing the manager isn't an option, either.

Educate the manager. Keeping shoddy code in production is a gamble:
you're gambling that the cost of fixing the code *now* is higher than
the cost of fixing it when it breaks or when there's a crisis. This is
almost never the case, and a competent manager will realize this. But
the risk of fixing the code now is that you'll break something that's
working, and that's often the key factor in "if it ain't broke, don't
fix it" decisions.

Put together a test suite that tests the existing code for correct
behavior, after establishing exactly what the desired behavior is. Be
complete in your tests, and use any available tools to make sure that
the code is all tested. Then replace the scripts one by one, making
sure that they pass the test suite. You'll probably find a lot of bugs
this way.

The test suite is an asset to the code base, especially when it's
automated, because you can verify that any code you change doesn't break
anything that was previously broken. And when you *do* break something
that was previously broken but wasn't tested, you can add to the test
suite.

And then, the next time you have a crisis, you can add tests
immediately. Or, when you're doing development at a sane pace, you can
write the tests first.

Charlton


--
Charlton Wilbur
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Josef Moellers
Guest
Posts: n/a
 
      10-16-2008
Following up on myself, after having given it some more thoughts:

Josef Moellers wrote:
> cartercc wrote:
>
>> How do you deal with a manager who tells you to leave a script alone,
>> when you know good and well that it's such poorly written code that it
>> will be extremely hard to maintain, and perhaps will be buggy as well?
>> Getting another job isn't an option, and firing the manager isn't an
>> option, either.

>
> Just give it to him in writing. If you later get into trouble, at least
> you told him before! Maybe one day he'll listen.


Maybe the best advice, which will not help you in this case, is that you
should force yourself to write good, well documented code in the first
place. Make it a habit, even for Q&D programlets: write down what the
program does, add a comment every time you have to think even for the
fraction of a second about how to do something, use boilerplates for
subs, ... the lot.. Depending upon your workload, you'll never get the
chance to clean it up afterwards, but you'll most likely will have to
return and fix it.
Writing good, well documented code does not take much longer than
hacking together bad, sloppy, undocumented code, but the resulting code
will be of much better quality, as you will have given it a second
thought when you wrote the documentation (i.e. comments, POD, ...).

I may sound sarcastic, but maybe it's a lesson that you have learned the
hard way.

I, for one, have.

Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html
 
Reply With Quote
 
cartercc
Guest
Posts: n/a
 
      10-16-2008
Thank you all. Every post had something valuable, and I appreciate all
the input.

As to writing good code to begin with, it's easier said than done.
When it's almost midnight, and you've been at work for about 14 hours,
and you have people (not just your manager, but his boss, the big
boss, and the guy in charge of the project) calling you every 15
minutes, and the people you had promised things mad at you because you
were tasked with doing a job THAT THEY KNEW ABOUT FOUR WEEKS AGO BUT
DIDN'T GIVE YOU A HEADS UP (!!!) ... well, pretty code takes a back
seat.

Particularly when the guy who should be showering you with praise for
performing over and beyond the call of duty will the very next day
will blame the programmer for the project being late, omitting the
fact that the programmer wasn't even told about the project until the
day of the deadline.

My solution is to teach my manager (who came by his position as a
result of a management background and has no grounding in IT ...
couldn't program Hello World if his life depended on it) how to
program under the explanation that he should know what's involved. The
result: he hasn't learned how to program but he HAS learned how to
look at a project from a technical point of view.

On Oct 16, 12:48*am, Charlton Wilbur <(E-Mail Removed)> wrote:
> >>>>> "cc" == cartercc *<(E-Mail Removed)> writes:

>
> * * cc> How do you deal with a manager who tells you to leave a script
> * * cc> alone, when you know good and well that it's such poorly written
> * * cc> code that it will be extremely hard to maintain, and perhaps
> * * cc> will be buggy as well? *Getting another job isn't an option, and
> * * cc> firing the manager isn't an option, either.
>
> Educate the manager. *Keeping shoddy code in production is a gamble:
> you're gambling that the cost of fixing the code *now* is higher than
> the cost of fixing it when it breaks or when there's a crisis. *This is
> almost never the case, and a competent manager will realize this. *But
> the risk of fixing the code now is that you'll break something that's
> working, and that's often the key factor in "if it ain't broke, don't
> fix it" decisions.


I mostly grab data from one place, massage it, and send it to another
place. The format of the data I get, and/or the format of the final
form, changes several times a year. It's not that the code breaks a
lot, but that the specifications change. Since we can't 'fix' the
specifications, we have to 'fix' the code, and guess who gets blamed
if the code isn't 'fixed.'

Thanks, CC.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Japanese banking crisis- the details Aardvark Computer Support 2 04-16-2009 10:38 PM
Ballmer says Microsoft can survive crisis abhi Wireless Networking 0 09-30-2008 05:18 PM
HP Laptop Identity crisis Jim Computer Support 7 11-15-2006 09:34 PM
DVD REVIEW -- "Crisis: Behind A Presidential Commitment" (1963)(The Robert Drew Collection) David Von Pein DVD Video 0 11-10-2006 02:56 AM
Please help..again. New install of XP and new PC crisis.... Gorbag Computer Support 3 01-19-2004 11:36 PM



Advertisments