Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Bad Karma = Bad Code

by frankus (Priest)
on Aug 13, 2002 at 16:48 UTC ( #189868=perlmeditation: print w/replies, xml ) Need Help??

Ever had a really bad day?

Pointy Haired Manager saying: That needs to go there... no there... put it back where it was before...why doesn't it work now?...that's in the wrong place...who told you to change that?
Well I have and I've found a pattern to the effect that this has on my code.

  • Comments disappear
  • Regular expressions become more prevailent and the e modifier is used with frightening and increasing frequency
  • maps and greps gather on lines
  • back ticks leap out of the ether
  • Comments are used to add sardonic humour
  • heredocs or formats are used in all their terrifying special cases
After building up a whole raft of maintenace problems for myself I leave for home.


Brother Frankus.


Replies are listed 'Best First'.
Re: Bad Karma = Bad Code
by FoxtrotUniform (Prior) on Aug 13, 2002 at 16:57 UTC

    I have, fortunately, never been subjected to quite that level of micromanagement. My bad days usually involve two different projects blowing up at the same time, generating large numbers of panicked phone calls which bounce me from fix to fix like a ping-pong ball, since they're all "stop what you're working on and fix this" requests.

    When that happens, my code tends to become plodding and tedious, programming by brute force and ignorance. I've been lucky enough to have found time later to fix that code, so far. With a little help from my friends, of course.

    It's interesting to see how differently we react to stressful coding environments.

    F o x t r o t U n i f o r m
    Found a typo in this node? /msg me
    The hell with paco, vote for Erudil!

Re: Bad Karma = Bad Code
by Ovid (Cardinal) on Aug 13, 2002 at 17:18 UTC

    My company is finally moving (crawling) towards Extreme Programming. One of the really nice things about XP is that it avoids the problem you describe. Whenever business people make technical decisions, we technical types tend to writhe in agony ("What do you mean I have to use Oracle and Java? I just wrote a 3-line Perl script that does the same thing.").

    However, it goes both ways. The business types get upset when the tech people try to tell them what to do. I worked on one project where the tech staff voted unanimously to use product X, but management picked product Y. The tech people were mad as hornets, but we had a deadline mandated by federal law and the far superior product X would take so long to setup and train users that we were guaranteed to miss the deadline.

    XP is nice because the business decisions and the technical decisions are separated. If I'm handed a story card that says every button on a form must be hot pink and moo when a user clicks on it, I just have to trust that the customer knows what he/she is doing. In turn, they have to trust that I know what I am doing. It's a very nice way to go about things.


    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Re: Bad Karma = Bad Code
by dws (Chancellor) on Aug 13, 2002 at 17:45 UTC
    Pointy Haired Manager saying: "That needs to go there... no there... put it back where it was before...why doesn't it work now?...that's in the wrong place...who told you to change that?"

    We make more of our Karma than we realize. Often, "bad karma" comes from having unconsciously conditioned those around us on how to get the results from us that they desire. (Ponder how cats train us.)

    If you've got a PHB hanging over your shoulder, chances are good that they believe it works to do so. You've got to change that, if possible without angering your boss. Electric cattle prods are good for conditioning some animals, but not bosses.

    A good start is to tell your boss, in as neutral terms as possible, how you see the situation and what you see the outcome as. Use your list of outcomes. Then follow with something like "If you tell me what to do, rather than how to do it. The result will be better. I'll be less frustrated by this situation, and the resulting code will be better. Are you willing to try that?"

    But be prepared for "no".

    You might also give some thought to whether your boss's directives make sense.

Re: Bad Karma = Bad Code
by thelenm (Vicar) on Aug 13, 2002 at 17:00 UTC
    ++frankus... How did you know? I've learned to deal with this kind of thing by doing whatever I can to keep my code flexible, readable, and maintainable (not to mention correct). Because I know that I'm the one who will pay for it in the end if my code doesn't meet those standards.

    It's not easy to plan for future change, especially when you're on a tight deadline and your boss wants changes quickly. Still, each time I hear the little voices in my head saying, "It's only a temporary change, it's okay to stick in this kludge for now...", I try to resist it. Each time I feel like cutting and pasting, I remind myself that it doesn't take that much more time to pull the common code into a subroutine. Each time I feel like sidestepping something that does take time, I remind myself that it will take even more time in the future to undo my sloppy changes.

    Anyway, it's tough, and I'm right there with ya. :-)

    -- Mike


      On quite a bit of a tangent, I'm looking forward to the well-defined Perl6 grammar that will allow us to do stuff like advanced LISP modes in some editors/IDEs allow: select some code and have it factored out into a subroutine with all local variables declared and everything necessary to make it work as it did in its old place, while substituting an equivalent function call to it in the place where that code was. Extraordinarily convenient.

      And ++ to frankus :-)

      Makeshifts last the longest.

Re: Bad Karma = Bad Code
by seattlejohn (Deacon) on Aug 13, 2002 at 17:56 UTC
    Sounds frustrating. Perhaps you just wanted to vent (understandable enough ;-), but here are some practical suggestions that might make your life easier:
    • Use source control.
    • Use bug-tracking tools.
    • Build (and use!) automated test cases.

    Source control is absolutely indispensible when the PHB says "put it back the way it was before", or when you realize your change broke something, or that you mistakenly nuked some important comments. CVS isn't the most user-friendly solution IMHO, but it's in widespread use and is free.

    Bug-tracking tools help you keep track of change requests -- whether they come from the boss, from one of your users, or from yourself ("I know this will be a maintenance nightmare later") -- in a logical way. If Bugzilla or something like that is overkill, at least open up a spreadsheet so you have all the bug/change requests in one place and can prioritize them.

    Automated test cases will let you sleep soundly at night -- and will likely give you a huge productivity boost too. Assuming you do eventually get around to cleaning up the messy code created in the urgency of the moment, how do you know it still works properly? (For that matter, how do you know it worked right in the first place?) If you have solid tests, though, you can feel confident replacing the hacks in your code with better-thought-out solutions -- and doing things like refactoring, too.

    Sorry if I'm preaching to the converted here, but I suspect there are at least some monks lurking around here who haven't yet experienced the thrill of adopting these techniques and seeing them mitigate what could've been a really painful situation...

Apply common horse sense
by Anonymous Monk on Aug 13, 2002 at 22:32 UTC
    Today drunk drivers are a problem because a car will blithely do what the driver says, even if that means running into something. But when people rode horses, drunk riders were far less of a problem. Not because the riders were better able to control the situation, but because a horse does not blithely do what it is asked, but instead exercises its own judgement.

    You are that horse. Some day your current task will be replaced by a fancy compiler/IDE/toolkit, but it hasn't happened yet. And until it does, your greatest strength and weakness is the ability to exercise your own judgement. Use that ability wisely.

    Blindly following bad directions leads you where you don't want to go. You know that. Trying to arrange everything for your comfort and convenience does not leave your manager with the flexibility that they need. They know that. So you both have to meet in the middle, and you should play your part in arranging that.

    First practice balking. Try to anticipate consequences. If you are told a change that you think will cause problems, say that up front. If person A wants you to do something that you think will cause person B problems, tell person B and A of the conflict at the same time, and refuse to proceed until the potential problem is resolved or OKed. (This is how you solve the ID10T who tries to get their way with an endless stream of change requests out of band.) Make sure that you have a record of potentially bad decisions.

    Next pay attention to the details that are properly your province. Yes, a rider gives a horse many instructions. But the horse has to do much more than instructed. The rider may indicate a direction, but it is the horse's job to avoid trees, place its feet carefully, decide when to jump over obstacles and so on. Except when it is for show (eg parades and certain competitions), it is foolish for the rider to direct a horse that finely.

    Therefore make it your decision to (even if the company does not) keep up basic best practices. Use source control. Choose a maintainable style and keep it up. As code gets hairier and hairier, constantly reorganize and simplify it so that it stays under control. Don't put in comments that you know will likely come out later. Make the time to think up potential problems and head them off now, while the code is fresh, instead of later when it is harder to debug.

    And if all else fails, you have a choice that the horse does not. You can choose to be quit of your current situation in search of another one. Which may or may not be an improvement, and may or may not be readily findable in today's economy. But still the awareness that you really can choose does wonders for your stress. If you are tired of being alternately spurred on and reined in, do not be afraid to bridle at the bit and say, neigh!

Re: Bad Karma = Bad Code
by Zaxo (Archbishop) on Aug 13, 2002 at 17:02 UTC

    Don't forget about the comments that linger on, reflecting a parallel universe and its alternate reality.

    There's a lot to be said for a rigid design process. Those things are annoying, but they generally outlast a manager's patience with doing your job for you.

    After Compline,

Re: Bad Karma = Bad Code
by tstock (Curate) on Aug 14, 2002 at 05:10 UTC
    So many great suggestions above, wow.

    I'll add this tiny idea... leave one or two obvious, glaring mistakes in your next project, let the pointy-haired-manager point them out, thereby satisfying his need for control. Take sweet time fixing to show respect for his observation skills, go home.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://189868]
Approved by FoxtrotUniform
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (7)
As of 2020-05-26 18:15 GMT
Find Nodes?
    Voting Booth?
    If programming languages were movie genres, Perl would be:

    Results (150 votes). Check out past polls.