Sometimes null



  • Just found in our codebase:

     

     SomeType1 item1 = someMap1.get(someKey1);
    SomeType2 item2 = someMap2.get(someKey2);

    if (item1.isEmpty() && item2 != null && item2.isEmpty()) { ... }

    What if item1 is null?

    I was running a massive test with hundreds of thousands of test cases, and every last one of them threw an exception on this. When queried, the developer who checked it in indicated that he coded it and checked it in, but didn't bother to test it because it would be vetted when other people did their work.

    Ok, that may be technically true, but fucking offshore developer !!!

    </rant>



  • Wow.... just.... wow.... that response baffles me.



  • For the record, I made him fix it, if only to force him to think for 10 seconds, thenr estarted my run, and found... yet another place with an uninitialized variable (-MAX_INT) being used as a map key leading to yet another null pointer.

    I sent out a flame mail to the entire team (he's not the only one who pulls this) explaining the cost of NOT checking for null/uninitialized values, and that I was going to buy a CAR with the money I was going to bill because of their pathetic work ethic.

    They were stupid enough to try and make light of it.

    I quietly sent a copy of the entire email exchange (including the original referenced in the post) to a higher level manager (someone who is responsible for money); she was not amused and asked me in to her office to explain. I did. She asked what needed to be done. I explained that this attitude is pervasive amongst inexperienced (e.g.: low cost) people, and that they are more expensive in the long run when it takes twice as long to get something into production.

    Any bets on whether anything good (besides me being able to vent here - thanks for listening) comes out of this?

     

     



  •  @snoofle said:

    didn't bother to test it because it would be vetted when other people did their work.
     

    Just reading that response pissed me off. Thanks



  • @snoofle said:

    ...but didn't bother to test it because it would be vetted when other people did their work.
     

    Did your offshore development team come from Majong (the Minecraft guys)?

     



  • @Sutherlands said:

    Wow.... just.... wow.... that response baffles me.
    Ponder for a moment what that means RE: code quality throughout.

     I mean what the fucking fuck? I can't be the only guy on this site that makes all his code into an API.  The notion of passing a bug like that on to ANYONE - even a developer - even one of my employees - is absolutely alien to me.

     That must be one WTF code base - or the OP must be a really busy beaver.

     



  • @mott555 said:

    @snoofle said:

    ...but didn't bother to test it because it would be vetted when other people did their work.
     

    Did your offshore development team come from Majong (the Minecraft guys)?

     

    No, they're all sitting right here in the same office - they just shipped over a few months ago.

    Right now, there are 3 of them standing around looking at it, scratching their heads, trying to figure out how a pointer might be null in a map.

     



  • Is "vetting" when you apply the contents of a veterinarian? I am unable to be upset about this response until I know what that word means.



  • @snoofle said:

    Any bets on whether anything good (besides me being able to vent here - thanks for listening) comes out of this?

     

     

    In my past experience, I was once told by two managers (in the same room at the same time), that, "While we appreciate your 110%, sometimes we are just looking for your 90%." This was said to me because I was one of the only two developers at that time who actually tried to adhere to the agreed-upon standards that the entire team (i.e., developers, managers, and QA) developed. It's a sad state of affairs, but when you come up against an attitude like this, nothing good can come from it. Even if the manager were to side with you, the other developers are going to know you as "that asshole who runs and cries to management", or when the manager doesn't side with you, you're known as, "the developer who doesn't work well with others". Either way, you're reputation is screwed. As cavalier as it sounds, you really are probably better off getting your affairs (and resume) in order and begin looking for a new job.



  • @dhromed said:

    Is "vetting" when you apply the contents of a veterinarian? I am unable to be upset about this response until I know what that word means.

    On the off-chance that you actually do not know what "vetting" is, it means to go under review. More specifically:

    [b]vetting[/b] present participle of vet (Verb)
    1. Make a careful and critical examination of (something).


  • @dhromed said:

    vetting

    Sorry - Wall Street lingo - vetting == trying something out/testing it.

    I just had a verbal blowup with this idiot and his supervisor. Apparently, they only check in the jar for a project when it's been tested. Code can be checked in in any state. So, if you (as another developer on the team) update your code and get the untested code, you can just use the jar from the repository instead of the jar you build locally.

    But what if both you and the other person wrote code in the same project? Your jar will contain your new code and their new broken code. The jar from the repository will contain old good code but not your code. it doesn't matter which comes first on the classpath - you can't do your work.

    This all stems from the fact that these guys are used to working on a team of 3 folks, where no two people ever run into each other. Now the team has 12 folks, and this crap happens all the time.

    I explained that it's ok to check in untested code as long as a) it compiles properly, b) there is a way to bypass it (eg: if (false) {untested code here} ), and c) it doesn't prevent anybody else from using the rest of the application. It took 45 minutes to make this simple concept sink in.

     


  • ♿ (Parody)

    @snoofle said:

    Any bets on whether anything good (besides me being able to vent here - thanks for listening) comes out of this?

    The money person taking an interest is a good sign for the company. OTOH, how are we defining "anything good?" Better code? A new car for snoofle? Revoked visas and a slow boat back for the defective devs?



  • @snoofle said:

    @dhromed said:

    vetting

    Sorry - Wall Street lingo - vetting == trying something out/testing it.

    I just had a verbal blowup with this idiot and his supervisor. Apparently, they only check in the jar for a project when it's been tested. Code can be checked in in any state. So, if you (as another developer on the team) update your code and get the untested code, you can just use the jar from the repository instead of the jar you build locally.

    But what if both you and the other person wrote code in the same project? Your jar will contain your new code and their new broken code. The jar from the repository will contain old good code but not your code. it doesn't matter which comes first on the classpath - you can't do your work.

    This all stems from the fact that these guys are used to working on a team of 3 folks, where no two people ever run into each other. Now the team has 12 folks, and this crap happens all the time.

    I explained that it's ok to check in untested code as long as a) it compiles properly, b) there is a way to bypass it (eg: if (false) {untested code here} ), and c) it doesn't prevent anybody else from using the rest of the application. It took 45 minutes to make this simple concept sink in.

     

    When I worked at a large defense contractor, one of the other managers in the large project insisted that her employees check in their code every day before they leave. (What happens if you get hit by a bus?!)  This caused the rest of us to be building a broken project.  That eventually got fixed, but said same manager eventually became my manager, and insisted that the code metric of 1:1 ratio of comments:code be adhered to in code reviews.  (Code included lines with only a brace)  That practice also got fixed by higher management...


  • @dohpaz42 said:

    @snoofle said:

    Any bets on whether anything good (besides me being able to vent here - thanks for listening) comes out of this?

     

     

    In my past experience, I was once told by two managers (in the same room at the same time), that, "While we appreciate your 110%, sometimes we are just looking for your 90%." This was said to me because I was one of the only two developers at that time who actually tried to adhere to the agreed-upon standards that the entire team (i.e., developers, managers, and QA) developed. It's a sad state of affairs, but when you come up against an attitude like this, nothing good can come from it. Even if the manager were to side with you, the other developers are going to know you as "that asshole who runs and cries to management", or when the manager doesn't side with you, you're known as, "the developer who doesn't work well with others". Either way, you're reputation is screwed. As cavalier as it sounds, you really are probably better off getting your affairs (and resume) in order and begin looking for a new job.

    <br/ >
    I have to agree with this; the nail that sticks up gets hammered down, in my experience.


  • ♿ (Parody)

    @Sutherlands said:

    When I worked at a large defense contractor, one of the other managers in the large project insisted that her employees check in their code every day before they leave. (What happens if you get hit by a bus?!)  This caused the rest of us to be building a broken project.  That eventually got fixed, but said same manager eventually became my manager, and insisted that the code metric of 1:1 ratio of comments:code be adhered to in code reviews.  (Code included lines with only a brace)  That practice also got fixed by higher management...

    Heh....this sounds like it should be in the other "git vs svn" thread. Also...how many comment lines is the following?

    /*
     *
     * Add 1 to x
     *
     */
    


  • @boomzilla said:

    @Sutherlands said:
    When I worked at a large defense contractor, one of the other managers in the large project insisted that her employees check in their code every day before they leave. (What happens if you get hit by a bus?!)  This caused the rest of us to be building a broken project.  That eventually got fixed, but said same manager eventually became my manager, and insisted that the code metric of 1:1 ratio of comments:code be adhered to in code reviews.  (Code included lines with only a brace)  That practice also got fixed by higher management...
    Heh....this sounds like it should be in the other "git vs svn" thread. Also...how many comment lines is the following?
    /*
     *
     * Add 1 to x
     *
     */
    
    5 ;)


  • @snoofle said:

    For the record, I made him fix it, if only to force him to think for 10 seconds, thenr estarted my run, and found... yet another place with an uninitialized variable (-MAX_INT) being used as a map key leading to yet another null pointer.

    I sent out a flame mail to the entire team (he's not the only one who pulls this) explaining the cost of NOT checking for null/uninitialized values, and that I was going to buy a CAR with the money I was going to bill because of their pathetic work ethic.

    They were stupid enough to try and make light of it.

    I quietly sent a copy of the entire email exchange (including the original referenced in the post) to a higher level manager (someone who is responsible for money); she was not amused and asked me in to her office to explain. I did. She asked what needed to be done. I explained that this attitude is pervasive amongst inexperienced (e.g.: low cost) people, and that they are more expensive in the long run when it takes twice as long to get something into production.

    Any bets on whether anything good (besides me being able to vent here - thanks for listening) comes out of this?

     

     

    mmph ... learned the hard way that making angry doesn't get anywhere. Ridicule can do, if you play it correctly (two weeks after a started a particular job I started a file of WTFs I'd found in the codebase I was working on, complete with smartarse comments, and passed it round), but perhaps the safest way is by crafting a detailed timesheet with cost of fixing the various bugs, whose checkin it was that caused it, etc. etc.

    Having said that, you may also find that there are two levels of required standards for code: those working on customer-facing, money-making projects (i.e. the stuff which the other guy is working on), where the only criteria seems to be that it's written loosely using the Western alphabet, and backup systems, maintenance applications and internal tools where the slightest sniff of a possible bug is grounds for failing to achieve your objectives come appraisal time (and of course that's the stuff you're involved in).

    Get that CV up to date.



  • @mott555 said:

    @snoofle said:

    ...but didn't bother to test it because it would be vetted when other people did their work.
     

    Did your offshore development team come from M[b]o[/b]j[b]a[/b]ng (the Minecraft guys)?

     

     

    FTFY. If you're going to insult people (even people who deserve it), at least spell their name right.

     



  • I'm not a developer, but what you said seems to be some very basic rule of professional coding, right? The way I see it, there shouldn't even be a discussion about this; that other developer's answer should have been "Oh ****, you're right! Thanks for pointing it out!".

    Besides, is there any reason to not run the test suite against all changes, even local ones?

    I'm not sure that mentioning the "buying a car" thing will help the situation, but still, I think you did the right thing. Management is always clueless and the only people how can point out this ... unprofessionalism are other developers.

    I was once asked to rate a developer, and didn't want to be "that guy who rats people out", so he got to stay for another painful, long year. Won't do it again.


  • Garbage Person

    @beermouse said:

    Besides, is there any reason to not run the test suite against all changes, even local ones?
    Absolutely - if you run the test suite, you'll find out how broken your shit is and it'll hurt your morale. And your per-line-of-code paycheck.



  • @Sutherlands said:

    Wow.... just.... wow.... that response baffles me.

     

    It does? I take it you've never worked with Offshorians.

     



  • @Matt Westwood said:

    <snip>

    but perhaps the safest way is by crafting a detailed timesheet with cost of fixing the various bugs, whose checkin it was that caused it, etc. etc.

     

     

     

    It won't matter. The extra cost of your fixes will still be peanuts compared to the bajillionty dollars they (think they) are saving. 

     



  • @Weng said:

    @beermouse said:

    Besides, is there any reason to not run the test suite against all changes, even local ones?
    Absolutely - if you run the test suite, you'll find out how broken your shit is and it'll hurt your morale. And your per-line-of-code paycheck.


    TRWTF is that you're not running something like CruiseControl or Hudson which automatically runs the unit tests whenever anything gets checked in.



  • @SQLDave said:

    @Sutherlands said:

    Wow.... just.... wow.... that response baffles me.

     

    It does? I take it you've never worked with Offshorians.

    Nope.  And I hope I don't have to.



  • @SQLDave said:

    @Sutherlands said:

    Wow.... just.... wow.... that response baffles me.

     

    It does? I take it you've never worked with Offshorians.

    I have worked with 'Offshorians'.  While I've heard that response multiple times, it still baffles me.  But not as much as the management responses to competent developer responses to said Offshorian response.

    Note: I've actually heard management claim that it was the local team's fault that the project was a year overdue, and 120% over budget, despite the fact that the 'offshore' developers had not, at any point in time, actually produced something stable enough to demo, and it was rare for them to actually get a complete build.  That particular project was salvaged by the star of the local team doing a hack at home, in a language of his choice, during his off hours.  It didn't have all of the features of the original spec, but it demoed successfully, and was about 85% correct overall.  It had all of the functionality of upper management's scaled back "let's just get something to 'ship'" requirements list.  A year after being deployed, the rest of the functionality was completed and stable.  Yet, when management found out it wasn't the 'offshore' developers' code about a year after that, they were livid.  They felt they'd spent so much money on the 'offshore' development team, they should be benefiting from it.  They were upset that the local team took it upon themselves to throw it away.  This, despite the fact that the only reason they had the successful demo was that the star developer decided to make a product substitution on a day when the 'offshore' team had a demo scheduled, but announced they needed to cancel because they couldn't get it to build.

    I'm not going to be able to fill in much more in the way of details, because it was a long time ago, and I wasn't on the team.  I was, however, really glad I wasn't on the team.  I did, at least, review some of the code that did make it into production.

    ('offshore' is in quotes above, because the developer team in question was on the same continent.  However, still a third world team "working" for a first world company.  And, while none of the 'offshore' developers spoke Hindi, or any other Indian language, they did all speak an 'Indian' language, and only a couple spoke English.)


  • Garbage Person

    @tgape said:

    'offshore' developers
    Your quotes are misplaced. You meant to say "offshore 'developers'"



  • @Weng said:

    @tgape said:

    'offshore' developers
    Your quotes are misplaced. You meant to say "offshore 'developers'"

    Actually, i think he meant "'offshore' 'developers'"



  • @Sutherlands said:

    @Weng said:

    @tgape said:

    'offshore' developers
    Your quotes are misplaced. You meant to say "offshore 'developers'"

    Actually, i think he meant "'offshore' 'developers'"
     

    So, local bakers?

     



  • @Sutherlands said:

    @Weng said:

    @tgape said:

    'offshore' developers
    Your quotes are misplaced. You meant to say "offshore 'developers'"

    Actually, i think he meant "'offshore' 'developers'"

    According to my friends, these guys did actually develop stuff.  In fact, they developed a *lot* of stuff.  It's just that none of it worked, is all.

    As it happens, I just got off the phone with one of said friends; I had mentioned this thread.  He reminded me of their development practice:

    The 'offshore' 'developers' were each trained in one job, and just did that job.  This meant that neither of the pair who spoke English knew anything about programming, debugging, testing, or software in general, beyond the email program used for most of the communication with the customers.  The programmers did not know how to run the compiler.  The guy who ran the compiler didn't know how to program, or how to do email (only one guy knew the compiler, and when he was out, no build was even attempted).  The list goes on.  So, in addition to the translation issues, there was also the 'telephone game' type problems with everything.



  • @tgape said:

    @Sutherlands said:
    @Weng said:

    @tgape said:

    'offshore' developers
    Your quotes are misplaced. You meant to say "offshore 'developers'"

    Actually, i think he meant "'offshore' 'developers'"

    According to my friends, these guys did actually develop stuff.  In fact, they developed a *lot* of stuff.  It's just that none of it worked, is all.

    As it happens, I just got off the phone with one of said friends; I had mentioned this thread.  He reminded me of their development practice:

    The 'offshore' 'developers' were each trained in one job, and just did that job.  This meant that neither of the pair who spoke English knew anything about programming, debugging, testing, or software in general, beyond the email program used for most of the communication with the customers.  The programmers did not know how to run the compiler.  The guy who ran the compiler didn't know how to program, or how to do email (only one guy knew the compiler, and when he was out, no build was even attempted).  The list goes on.  So, in addition to the translation issues, there was also the 'telephone game' type problems with everything.

     

    THAT explains the "purple monkey dishwasher" error message I got the other day.

     

     


Log in to reply