But It Works For Me



  • This actually happened this morning...

    One of our developers rolled out a new version of one of our internal web apps on Friday evening. He took Monday off, so I had to do post-rollout support. Monday morning a user contacted me and said she couldn't use one of the features that were touched in the rollout. I dig into the code and the problem is that a JavaScript statement was accidentally terminated with a comma instead of a semicolon. I fix it and roll the fix out. None of the WTFs in this paragraph are the biggest WTF.

    This morning the developer comes in and asks me how yesterday went. I mention the comma bug and tell him the commit number so he knows what's up. I didn't make a big deal of it, so I think it's over. Ten minutes later, he calls me over to show me that the old code with the comma works for him. I respond with, well it didn't work for some people and it's clearly invalid. He continues trying to justify the old code and even rolls the comma back out to production to see if maybe he will get a different result there.

    Of course, the comma version still works on his browser there, so he's all "why did you change the code, it works". I simply say "It didn't work for some users and it's not correct, making it correct fixed it for them". He then asks why it works in his browser. I respond with "I don't know; browsers are designed to be tolerant, maybe whatever combination of stuff you are using can handle this particular situation. It doesn't matter, it's incorrect and breaks for some people".

    After five minutes of this, I finally had to end it with "Well, then roll the change back if you feel that way".



  • @Jaime said:

    After five minutes of this, I finally had to end it with "Well, then roll the change back if you feel that way".

    And since the last change was to

    @Jaime said:

    rolls the comma back out to production

    you made him rollback the rollback, thus ensuring the correct code stays there! Brillant!



  • He put the semicolon back after his "experiment".


  • ♿ (Parody)

    @Jaime said:

    One of our developers rolled out a new version of one of our internal web apps on Friday evening. He took Monday off...None of the WTFs in this paragraph are the biggest WTF.

    I submit that one of these sentences is arguably wrong.



  • Everyone who sits around me knows how much I love "but it works for me". I get to say, "It doesn't work for me, and it has to, so you have to fix it." I guess you don't get to say that?



  • Commas? Sounds like IE, it has issues with commas. Commas at the end of last object member declaration in JS will cause IE to shoot itself in the face.

    i.e.

    [code]
    var obj = {
    test: "1",
    test2: "2",
    }
    [/code]
    will work fine in every browser but IE with that last comma.

    It's why I feed my JS through Google's Closure compiler, it's able to bitch at you for possible incompatibility between browsers.


  • Discourse touched me in a no-no place

    @boomzilla said:

    I submit that one of these sentences is arguably wrong.

    Only one?


  • ♿ (Parody)

    @FrostCat said:

    Only one?

    I suspect the facts that @Jaime's cow-orker released something Friday night and took Monday off are easily verified by @Jaime and not really arguable. Perhaps you disagree, but that's a different room.


  • Discourse touched me in a no-no place

    @boomzilla said:

    I suspect the facts that @Jaime's cow-orker released something Friday night and took Monday off are easily verified by @Jaime and not really arguable.

    I didn't mean I believed he wrote them incorrectly.



  • I probably should have said "that's not what I want to talk about" rather than "None of the WTFs in this paragraph are the biggest WTF". I agree that it could be the biggest WTF, it's just so normal for me here that I didn't think it was worth bringing up.



  • @delfinom said:

    Commas?

    $.ajax({
       type: "POST",
       url: "xxx",
       data: yyy
    }),
        
       
    


  • Stuff like npm and bower also drop the ball on this.



  • Confirming Chrome will throw a syntax error on that extra comma, you can actually try it live on the discourse site.

    Funny enough the error is a bit off

    SyntaxError: Unexpected token }
    It seems to see the comma and think the previous object declaration should be continuing.

    Edit, IE11 just throws an "Syntax Error"



  • @Jaime said:

    ... JavaScript statement was accidentally terminated with a comma instead of a semicolon.

    I strongly recommend you petition to get setup with jslint through grunt and something like jenkins, then visualise the build-breakage to somewhere that the whole company can see. I am almost certain jslint would catch issues like that.

    It tests in phantomjs, which Captain Buttitworks is unlikely to use, so some cross-browser checking.

    Fancy not checking cross-browser. How long has Captain Buttitworks been a frontend dev for? Were they in a rush?

    Anyway, failing all that (a lot of setup, I know) make sure you're not in the firing line when Captain Buttitworks deploys his next (the same?) ingenious coding practises.

    Now that I think about it, if you've got a guy who releases broken code like this, you've probably got a few days of work on your hands just linting the code. Probably stepping out of the firing line is cheaper.



  • He's the guy who has been here forever, and I only have about a year in. I've been beating the JSLint drum for a very long time, but we have a long way to go. It's only recently that I have gotten him to actually submit builds - he used to deploy to production directly from his dev environment. Even that is a challenge - I recently found out that he kicks off builds, but then copies just the changed files, by hand, to where he deploys it. He also doesn't do testing on the built files, just on his dev environment.

    Also, I don't think this pile of crap is JSLint-able. The JavaScript is embedded in server-side code, which is classic ASP.



  • @Jaime said:

    he used to deploy to production directly from his dev environment.

    For my current project, we used to be able to directly deploy to production from our CI server where I work. Fortunately, once production went live, they started cracking down on that... now, only a sysadmin can move builds from dev to uat, or from uat to production. CI can still be used to deploy to the dev server.

    Granted, this is for Java webapps, so you just have to copy the ear[1] file around.

    [1] The fact that this is an ear instead of a war is an artifact of a previous wtf that is gone now. I mean, who the f' thought it was a good idea to embed the DB information and connection logic in the app instead of inside the appserver?



  • And is he getting paid for doing that?



  • I am currently employed at my first and last ever job where I will be primarily responsible for other peoples' code.



  • @Jaime said:

    He's the guy who has been here forever...

    By the sound of things, he has the same year of experience multiple times, rather than multiple years of experience. I'm guessing he has enough diplomatic immunity to avoid getting into trouble for schoolboy errors such as forgetting cross-browser testing. The only times I forgot about cross-browser were when I was short on time, which in my first job was unfortunately all the time.

    @Jaime said:

    ... copies just the changed files, by hand, to where he deploys it.

    I had to work on a system where this was required. Fortunately we eventually upgraded to a system where we could check out into a sym-linked directory. You can probably tell by that sentence that we would have had a long way to go as well. Certain individuals were resistant to us having decent protocols, probably because it's easier to make false claims and point fingers that way.

    @Jaime said:

    Also, I don't think this pile of crap is JSLint-able. The JavaScript is embedded in server-side code, which is classic ASP.

    I find myself unsurprised. Good luck!

    @chubertdev said:

    I am currently employed at my first and last ever job where I will be primarily responsible for other peoples' code.

    How does that work? "It doesn't" is an acceptable answer.

    I had a job for a while being a 'liaison' instead of doing actual fucking development (not by choice). I learned the hard way that I could not take it on faith that the vendor was competent and fixed the bugs he said he fixed. I should have known better, this was just the effect of being so fed up with QAing the vendors work instead of, say, programming it myself cheaper and quicker and actually giving our company what we fucking wanted instead. The vendor wasted a lot of my time by fucking up, delivering information poorly or not actually fucking reading the messages I sent him properly.

    I mean seriously, if it has a screenshot with the button not existing, responding to me with a message that just tells me to press the non-existent button should make you look stupid, but somehow I'm the one accountable for the vendor I didn't hire.

    Next time I am in that position, I will insist on the power to fire the likes of the vendor.


Log in to reply