People shouldn't make mistakes



  • I recently did a rather invasive change to convert our application from mulltiple single threaded instances to one multi-threaded instance (mostly to save a massive memory footprint of 45+GB per server).

    We have to interface with another system, and the folks who wrote the code took the lazy way out and made all the methods static (they could have just as easily used instances of the objects). Our developers have a propensity to stick instance variables here and there without rhyme or reason.  While threading works just fine with static methods, once instance variables are introduced, all sorts of potential hard-to-track bugs can crop up. Rather than expose us (eg: these things would likely be reported as  threading "bugs" and I don't want to have to track these things down), I made the change from static utility class methods to instance methods (basically, just s/static//g andinstantiate the object rather than just referencing statically). I discussed it with my boss in advance, and he agreed it was prudent. We tested and it all worked. It seemed like a modest price to pay for insuring against a whole class of potential hard to track bugs.

    Along comes Mr. I-Know-Everythig-So-You-Must-Be-Wrong developer with 20 years of experience (none of which is working on threading) who starts sending emails that java doesn't require methods to be instance methods because of threading. I reply why we did it. He persists that folks could still introduce instance variables. I reply that it no longer mattered as the instance of the class would be different in each thread so there'd be no interference. He persisted that it wasn't necessary to make the static methods instance methods because developers should know what they're doing and shouldn't make mistakes.

    Parenthetically, they should know what they're doing, but people forget, or the new guy hasn't yet learned, or sometimes folks are just tired and make mistakes (folks know better than to walk out in the street without looking, yet how many folks stare at their phones and walk in front of a moving bus?)

    I pointed out that in the real world, sometimes defensive coding is your best policy. But what if someone shared a class instance between threads. Well then they KNOW they're crossing thread boundaries and should use appropriate synchronization.

    This went on for about two hours (via email) until my boss finally told the guy to shut up and knock it off unless he wanted to rewrite the entire application. I suggested that the only way I'd go along with that was if this guy personally took full responsibility for tracking down all threading related issues. He declined.

     



  • It's funny to see people that feel perfectly comfortable complaining and/or critisizing, yet when it comes time for them to suggest a better alternative or accept some responsability, they cower away.

    "Hey, you're doing it all wrong, dumbass!"

    "ORLY? Why don't YOU do it then?!"

    "Um, nevermind..."

    Classic sign of someone who suffers from an inferiority complex.



  • And the flipside is a culture in which everybody keeps stumm and nobody suggests improvements or changes for fear of being assigned the responsibility of implementation.

    I've met with just that mindset recently: it was a meeting to propose and discuss improvement opportunities, and the last action the chair did was to dole out each opportunity as an assigned project. I objected on the grounds that I thought this was simply a meeting to discuss and collate said improvements - and if we'd have known that they were all going to be approved, we may not have been so forthcoming in suggestions.

    It didn't go down too well. I suspect the next meetings are going to be somewhat disengaging and quiet.



  • @Cassidy: Without knowing your workload, this may [not] be appropriate, but assuming they gave you the time to do the work, you turned down the opportunity to improve things? 

    I usually have to justify - pretty hard - every little change I want to make to make things better. Again, without knowing how reasonable management is, it would seem you have a golden opportunity there...



  • I know I ask this in every thread you post, but ... why do you work there again?


  • ♿ (Parody)

    @snoofle said:

    He persisted that it wasn't necessary to make the static methods instance methods because developers should know what they're doing and shouldn't make mistakes.

    Yeah, defensive programming sucks!

    But more seriously, even when dealing with people who do know better, after working for however long on a codebase where threading wasn't an issue, how difficult would it be to revert to old habits on occasion? Totally not worth the risk versus the effort involved of making things just work for the majority of cases.



  • @blakeyrat said:

    I know I ask this in every thread you post, but ... why do you work there again?
     

    a) pretty good pay

    b) entertainment value

    c) I get to pretty much come and go as I please



  • @snoofle said:

    @blakeyrat said:

    I know I ask this in every thread you post, but ... why do you work there again?
     

    a) pretty good pay

    b) entertainment value

    c) I get to pretty much come and go as I please

    d) My boss lets me kill my coworkers

    FTFY



  • @snoofle said:

    He persisted that it wasn't necessary to make the static methods instance methods because developers should know what they're doing and shouldn't make mistakes.
    My response would have been to ban all future use of "static" without management approval.  Freaking twit.



  • @snoofle said:

    @Cassidy: Without knowing your workload, this may [not] be appropriate, but assuming they gave you the time to do the work, you turned down the opportunity to improve things?
     

    No... but apologies for not making that clearer, in particular the nature of the work involved.

    I was led to believe it was an ideas meeting, and all ideas would be evaluated and approved/rejected accordingly. Implementation of each ideas would then be under control of someone running projects who would manage appropriate resources and scheduling as necessary. My beef is that we, as ideas people, may not be the best (and in many respects the cheapest) resource to handle implementation.

    Okay, TL;DR version: if you suggested that your office could do with a lick of paint, would it be cost-effective if your client sent you out to buy paint and you to do the job yourself (and still receive contracted pay rates)...?

    I welcome the opportunity to improve things - I just felt that the meeting had a hidden agenda and it's soured engagement of future participants.

    Hell, if Stephen Hawking came up with a new theory on time travel, I'd not challenge him to turn his wheelchair into a TARDIS.

     



  • @Cassidy said:

    Hell, if Stephen Hawking came up with a new theory on time travel, I'd not challenge him to turn his wheelchair into a TARDIS.

    Lot of fun you are...



  • Static members should generally be thread safe anyway.



  • @hoodaticus said:

    Static members should generally be thread safe anyway.

    Really?

    static Foo Bar { get; }

    public class Bar()

    {

       public int FooBar { get; private set; }

       public void Recalculate()

       {

          int temp1 = FooBar + GetDatabaseValue();

          int temp2 = FooBar + GetConfigValue();

          FooBar = temp2;

       }

    }



  • @morbiuswilters said:

    Lot of fun you are...

    LOLWUT? The guy's absolute NAILS!


    I ain't taking him on, dawg.



  • @Sutherlands said:

    @hoodaticus said:

    Static members should generally be thread safe anyway.

    Really?

    static Foo Bar { get; }

    public class Bar()

    {

       public int FooBar { get; private set; }

       public void Recalculate()

       {

          int temp1 = FooBar + GetDatabaseValue();

          int temp2 = FooBar + GetConfigValue();

          FooBar = temp2;

       }

    }

     

    Your parser failed a unit test at the word "should". Also, the word "static".

     

    should (v):

    1. Used to indicate obligation, duty, or correctness, typically when criticizing someone's actions: "he should have been careful".
    2. Indicating a desirable or expected state: "by now students should be able to read".

     



  • @Cassidy said:

    And the flipside is a culture in which everybody keeps stumm and nobody suggests improvements or changes for fear of being assigned the responsibility of implementation.
     

    I think this comes down to how the suggestions are made and received, and also how the dialogue progresses.  It would be sad if, as professionals and adults, we were unable to give or take suggestions without getting angry or defensive.



  • ♿ (Parody)

    @RTapeLoadingError said:

    It would be sad if, as professionals and adults, we were unable to give or take suggestions without getting angry or defensive.

    Fuck you! Our process is just fine!



  • @morbiuswilters said:

    @Cassidy said:

    Hell, if Stephen Hawking came up with a new theory on time travel, I'd not challenge him to turn his wheelchair into a TARDIS.


    Lot of fun you are...

    His point's perfectly valid. Hawking is recruiting for a minion to maintain his wheelchair (or was recently, anyway). It's the minion's job to do the practical implementation.

    Besides, the man has a reputation for running over people's toes when they annoy him.



  • @boomzilla said:

    @RTapeLoadingError said:
    It would be sad if, as professionals and adults, we were unable to give or take suggestions without getting angry or defensive.

    Fuck you! Our process is just fine!

     

    If your process is so good then why does everybody hate you and think you're an idiot and last week when we were at the pub and you went to the toilet we all laughed at your stupid new hair cut.




  • @boomzilla said:

    Fuck you! Our process is just fine!
     

    Hey, are you following the correct process defense process?



  • @hoodaticus said:

    Your parser failed a unit test at the word "should". Also, the word "static".

     

    should (v):

    1. Used to indicate obligation, duty, or correctness, typically when criticizing someone's actions: "he should have been careful".
    2. Indicating a desirable or expected state: "by now students should be able to read".

    So... your response to someone saying that you shouldn't make a class have instance methods instead of static methods is that the static method SHOULD be thread-safe?  So there's no need, because it SHOULD be that way?  Are you snoofle's coworker?

    Also, I'm pretty sure that there's a static instance at the top of my code sample, which is how most singletons are created.



  • No disagreement defensive programming, but people WILL make mistakes. Therefore, instead of arbitrary limitations preventing perfectly valid constructs, a robust set (not just unit and integration) of tests is the best defense. Until recently I would rent time on some supersalar machines (64 or 128 processors) to do fuzz testing agains core multi-threaded libraries I was developing. Now that the code is more stable at the core, and with the advent of i7 processors (and the purchase of a quad Xeon box) I have needed to rent capabilities for a while. But it was very enlightening to see some of the bugs that would only surface when running a large number of processors against heavy loads (orders of magnitude greater than anything that would exist in production) and sometimes would occur only a few times per hundred hours of run time.



  • @TheCPUWizard said:

    ...instead of arbitrary limitations preventing perfectly valid constructs, a robust set (not just unit and integration) of tests is the best defense.
    Agreed, but as I've posted before, we have very limited unit tests, and most of those are along the lines of:

     

    void testXXX() {
    int x = 0;
    assertEquals(0,x);
    }


    It's on the list, but until they let me do it, caution in an environment of "developers" like the guy in the post seems prudent.


Log in to reply