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

Re: Keeping, and advancing in, your job

by dragonchild (Archbishop)
on Mar 03, 2005 at 19:29 UTC ( #436337=note: print w/ replies, xml ) Need Help??


in reply to Keeping, and advancing in, your job

This is for everyone:

You are hired on at a multi-billion dollar company - their daily profit is higher than your lifetime gross pay. You are assigned to an older system that is a major service for a large, very profitable system. Surprise, surprise - they don't use strict. Do you

  1. Just do your job within the restrictions and keep your mouth shut
  2. Make a huge stink about strict and refuse to make any changes because "it's too dangerous"
  3. Do your job for a few months, then quietly mention to your immediate supervisor while you're having lunch that using strict would be a good idea

Less than 10% of all developers will do the latter option. Remember - this program was working long before you go there. It makes lots of money. Therefore, it's got to be doing something right.

Furthermore, change is expensive, especially without strict, testplans, and the other trappings that good developers like to have around them. Management is right to be wary of you. If you owned the company, you'd be wary, too.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.


Comment on Re: Keeping, and advancing in, your job
Re^2: Keeping, and advancing in, your job
by bwelch (Curate) on Mar 03, 2005 at 20:49 UTC
    4. Quietly make a copy of the system. As part of normal maintenance work, modify this copy to use strict and be 'safe' for testing. Run perl tidy on it and add comments as needed.

    Any script I receive goes through this process. For me, it's the most efficient way to adopt and start maintaining a system.

      Have you ever modified a 10_000 line module to use strict? You literally have to rewrite it, and everything else that uses it, from scratch. (This can easily get into the 100's of thousands of lines of code.) There is often no other way.

      Oh - does your quiet time also include writing the test cases? Refactoring without a test suite is like getting very drunk then tightrope-walking across the Niagara falls. Not something most of us feel is safe ...

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Sheesh. I didn't say it was easy, I only stated what works and was most efficient for me. It's easier and safer than trying to modify someone's code without comments, strict, or knowing what the changes might affect.

        Most developers here use modules and break up functionality decently even if they don't use strict. It makes sense. Break up large code into modules for easier testing, updates, and re-use. No, there's no need to rewrite it. And yes, adopting a system means using existing or writing test suites. Of course, the two printers next to my cube don't make it very quiet.

        Someone wrote a 10,000 line module ? And gave you no test harness ?

        Then the first part of refactoring is to bitchslap the original developer....

        ...it is better to be approximately right than precisely wrong. - Warren Buffet

      Quietly make a copy of the system.

      Yeah, and then later get charged with "felony theft", by some executives trying to cover up their "secret sale" of the scripts.


      I'm not really a human, but I play one on earth. flash japh
Re^2: Keeping, and advancing in, your job
by freddo411 (Chaplain) on Mar 03, 2005 at 22:38 UTC
    Less than 10% of all developers will do the latter option. Remember - this program was working long before you go there. It makes lots of money. Therefore, it's got to be doing something right.
    So I take it that option 3 is what you are advocating as a reasonable approach, while option 1 and 2 are less reasonable. I think that all of those options have upsides and downsides:

    • Option 1 upside: Get paid while it works.
      Downside: uncaught system bugs get you fired, perhaps.
    • Option 2 upside: Low stress at work.
      Downside: No job.
    • Option 3 upside: Get paid while it works.
      Downside: uncaught system bugs get you fired, perhaps.

    So I don't see a lot of difference in 1 and 3 until after your discussion with the boss. Even then the defacto corporate programming methods/policy isn't likely to be changed by your middle manager. After all you said it has been working the old way making $$$ so why change?

    OTOH, making changes to the Modules you modify, and applying more sane programming practices yourself, quietly, over time, would seem to be an option 4 which would be compatible with option 3 and perhaps more likely to change the defacto corporate programming practices? No?

    -------------------------------------
    Nothing is too wonderful to be true
    -- Michael Faraday

Re^2: Keeping, and advancing in, your job
by davies (Vicar) on Mar 04, 2005 at 13:35 UTC
    I'd prefer to add a fourth option. Go IMMEDIATELY to my supervisor and say something along the lines of, "You asked me to look at this. Mummy always told me never to leave 'strict' out, but my guess is that it would mean a complete rewrite, taking x months. Do you want me to do that, and if so, when?" This means that the supervisor is in a position to balance resources and projects, which is what I would expect a supervisor to be there for. The answer might tell you a lot of things, for example,

    "Bleep off & mind your own bleeping business": this is good advice to follow. Another employer should be sought ASAP!

    "What's strict?": you have an opening to become the indispensible perl guru in this firm.

    "We can't afford the time": it'll be more expensive later.

    Granted, I'm a beancounter, but I do seem to spend a lot of time on computer projects. Even in the beancounting world, the general approach is appropriate. Tell the man who makes the decisions what you think should be done and what resources it will require. Then let him do his job and decide. If you're worried about CYA, put it in writing. But I don't like 1 or 3, because you are keeping quiet about something other people need to know, and I don't like 2, because you are criticising other people's work, and they won't like it. You are painting a target on yourself.

    One final point, & I'll shut up. Always over-estimate the resources you will need. Not wildly, but leave a margin for things to go wrong. They will!

Re^2: Keeping, and advancing in, your job
by Paulster2 (Priest) on Mar 04, 2005 at 15:55 UTC

    From my view, there is one more option that you didn't mention here. That, IMHO, would be:

    4. Use strict in your own programing and quit worring about others programs (since it works) until the software breaks or you are required to modify it.

    You do make a very valid point.

    UPDATE: Sorry, this was in response to dragonchild's response above. Seems that his node has brought about much good debate! Luv, it.

    Paulster2


    You're so sly, but so am I. - Quote from the movie Manhunter.
Re^2: Keeping, and advancing in, your job
by sfink (Deacon) on Mar 08, 2005 at 06:58 UTC
    I've been there. But I recommend a somewhat different path:
    • Add use strict;
    • Write a one-liner that takes all of the resulting error messages and converts them into one massive, insanely ugly our ($x, $Time, @Names, $CurrentId, ...); statement and paste it into the top of the code.
    • Add lexical blocks beginning with no strict 'refs' around the remaining problem spots.
    • Go make the changes you needed to make in the first place.
    • Whenever you get stuck on a problem, convince yourself that it's somehow caused by reusing variables or some other idiocy that use strict would detect if you hadn't added that monstrosity to the top of the file.
    As a result, whenever you get frustrated from struggling endlessly with a nasty problem, you'll waste half an hour or so eliminating those awful global variables. Eventually, you'll get to the point where you're more sick of cleaning up that crap than you were sick of chasing after the original problem, and you'll go fix it. Over time, all those globals will gradually disappear.

    The bad side of this is that cleaning out the global variables will never fix the problem you're facing at the moment.

    The good side of this is that you'll discover and repair dozens of potential problems, and actual problems that people have learned to live with or assumed were intentional (albeit stupid) design decisions.

    The so-so side of this is that once you've made everything properly strict-safe, you'll realize that your new version really isn't substantially better than the original. The mindset that produced that many stricture violations is unlikely to have done a great job with the other parts of the system. But you will have a good understanding of what those problems truly are, much better than the initial knee-jerk reaction of disgust that you started out with. And that will enable you to start intelligently refactoring pieces without breaking the overall script (or needing to introduce so many adapters and bandaids that your "improved" version won't be.)

    At the risk of offending the fanatical refactoring devotees, I will also assert that even if you manage to refactor the crap out of the code, it's never going to be pretty. It is possible to turn a chicken into a horse by changing one piece at a time, but any sane programmer will start by throwing out the gizzard. As a result, he'll end up with a two meter tall winged herbivore that sleeps standing on one foot and outruns a greyhound -- but dies of starvation. Doing it right requires designing pretty much the whole horse in advance, and if you're going to do that, it'd be less work to just build the damn horse.

    But if you do, you won't have time to feed the chicken.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (16)
As of 2014-04-18 17:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (471 votes), past polls