• Q (unregistered)

    Master of Frist

  • Yazeran (unregistered)

    Wait.. No HTML comments?

    What have you done to the real Remy Porter? :-)

    Yazeran

  • Dave (unregistered)

    "Their PRs end up being lengthy flamewars over whether or not they should be following policies."

    Now that's trwtf. Just before the pr starts, go through all their old commits and get rid of any which don't follow policy. Then the pr goes 'you haven't checked in any valid code in the last six months, bye'.

  • Simon Clarkstone (unregistered)

    I think there is a mistake in the example of malicious code. AFAICT it should read:

    While a malicious config file would fail to do user_case_conf['downstrem_script'] = 'my_hostile_script', it could easily do user_case_conf.__setitem__('downstream_script', 'my_hostile_script').

  • Bluemoon74 (unregistered) in reply to Simon Clarkstone

    Is the mistake 'downstrem_script' vs 'downstream_script', because that looks like a typo to me ?

  • Scott (unregistered)

    It is never too late to fix the code. Incompetent people bitch about bad code, competent people refactor.

  • Bill (unregistered) in reply to Scott

    It is too late to fix the code if it has been delivered to the customer and they aren't interested in any updates.

  • (nodebb) in reply to Bill

    If I were the customer and I saw a config file that contained arbitrary Python to be executed, I'd definitely be interested in any updates. In fact, I'd be demanding updates.

  • Foo AKA Fooo (unregistered) in reply to Jeremy Pereira

    That's why you (I guess) and I are not customers, but developers.

    The actual customer probably already implemented some "clever hacks" of their own meanwhile, so this "feature" may never be changed. Even if in the future the application will be ported to another language, they'll have to keep calling a Python interpreter or (more likely) emulate what they think is Python syntax to read those "config" files.

  • Simon Clarkstone (unregistered) in reply to Bluemoon74

    Ooh, I didn't spot that typo; the typo I was fixing was one with an = sign in the expression that wasn't supposed to have one.

  • tbo (unregistered) in reply to Scott

    Unfortunately, refactoring doesn't make any money.

    Although, I've been trying to explain to my coworkers that there are two ways to "make money": by increasing revenue and decreasing (subsequent development) costs.

  • JimVC (unregistered)

    Say goodnight, Gracie. (Really old guys will get it.)

  • SlowMoe (unregistered)

    Configuration files contain all kinds of security-critical content: Install paths, security policies, passwords, API keys, you name it. And no-one ever bats an eyelid at that. The simple fact is that most of the time, configuration files need to be subject to the same security constraints as the application they are used by. And using eval'ed snippets of code is absolutely a viable approach.

    Gracie was right. George was wrong. Stupid won, and productivity suffers.

    <quote> no one really expected to see those code paths change significantly. </quote> Famous last words.
  • (nodebb) in reply to tbo

    "Unfortunately, refactoring doesn't make any money." ... Preventing the unnecessary expenditure of money is functionally equivalent to "making money""

  • steve76 (unregistered)

    My coding standards:

    Make it look as much as possible to the official tutorial. Everyone knows it, even you 2 months from now.

  • Chris (unregistered)

    "Unfortunately, refactoring doesn't make any money." Another point - providing higher quality code leads to a higher reputation. Or, supplying code with gaping security flaws leads to a poor reputation when said flaws cause problems (either deliberately or accidentally). Reputation is valuable; it is much harder to gain than to lose.

  • Barf4Eva (unregistered) in reply to Scott

    Wow, you never bitch about bad code but go about refactoring all of it? Well, at least you'd have a job forever here...

  • (nodebb) in reply to JimVC

    And if you're about thirty years younger go for the Shatner reading.

  • Potato (unregistered) in reply to SlowMoe

    I agree. This is a story about a person who used intentionally misleading mumbo jumbo about security to make a career move. Security is a great way to win arguments when management is involved, because security is poorly understood, but makes people vaguely scared - and what better way to make the scary thing go away than picking the "most secure" option. It's a dirty trick and it works every time, as any experienced developer knows.

    Having a policy of involving management in minor tech disputes like this one sounds like an absolute nightmare. Involving management instead of having the dev team agree on their own kills productivity and fosters discord among the devs - except for the Georges out there, who can use the opportunity to manipulate their way up the corporate ladder.

  • Little Bobby Tables (unregistered) in reply to Barf4Eva

    I do both ... that way I look good twice over.

    "I notice that the programmer of this module appears never to have heard either of code reuse or looping. Or, looking at it a little more closely, arrays, either. Or the singleton pattern. Or, well, never mind, I've rewritten it so it's now one tenth the size, and now it takes one twentieth the time to run."

  • SG (unregistered)

    We used to have plugin support not dissimilar to this in our application — after a number of (unintentional) cases where plugin code ended up interfering the application, I spent some time figuring out how to sandbox it... make it an actual plugin rather than letting the clients monkey-patch our code...

  • Scotty (unregistered)

    "George and Gracie"

    Admiral! There be whales here!

  • P. Wolff (unregistered) in reply to tbo
    Unfortunately, refactoring doesn't make any money.

    Although, I've been trying to explain to my coworkers that there are two ways to "make money": by increasing revenue and decreasing (subsequent development) costs.

    Try telling this to some PHB. You not enterprise think. Subsequent will be after bonus payout.

  • P. Wolff (unregistered)
    clever hacks were entirely possible.

    A good hack goes right through the log into your foot.

  • Darfman (unregistered)

    Some Dunning Krueger at it's best!

Leave a comment on “Yet Another Master of Evil”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article