|
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
| [reply]
[d/l] |
Re^2: Keeping, and advancing in, your job
by davies (Prior) 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! | [reply] |
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. | [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
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.
| [reply] |
|
|
|
|
|
|
| [reply] |
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.
| [reply] |
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.
| [reply]
[d/l]
[select] |