Existentialism



  • I'm starting to see so much sub-par code that I'm starting to second-guess myself. Do unit tests really matter? What's *really* wrong with stringly-typed code? What does it mean to have best practices? Best practices are for the best developers, and no one is perfect; as long as it works, right?

    Enforcing and communicating best practice (especially to non-native English speakers) takes so much time and effort; I'm talking full weeks' worth of communication and code reviewing. I could easily let the whole project turn rotten and use lazy practices to maintain the code.

    I think I'm slowly getting desensitized and am becoming apathetic. Does this ever happen to you?



  • @OhNoDevelopment said:

    Best practices are for the best developers
     

    That's exactly the wrong way around. "Best practices" are for the not-so-experienced developers, so that they have a few guidelines to hold on.



  • ... or rather, "best practises" have emerged as a result of watching good covers and documenting what they do as guidance for shit coders - in the hope they'll follow it and improve.

    For "follow", read "adopt, adapt, appreciate" rather than "percussively implement with a clue-by-four".



  • s/covers/coders/

     

    .. damn the edit expiry time.



  • @OhNoDevelopment said:

    Do unit tests really matter?
     

    No.



  • @dhromed said:

    @OhNoDevelopment said:
    Do unit tests really matter?
    No.

    There are entire huge classes of errors that unit testing is useless for. For example, the by-far most important part of your application, the UI? Yeah unit tests are useless as fuck there. So I agree.



  • @blakeyrat said:

    @dhromed said:
    @OhNoDevelopment said:
    Do unit tests really matter?
    No.
    There are entire huge classes of errors that unit testing is useless for. For example, the by-far most important part of your application, the UI? Yeah unit tests are useless as fuck there. So I agree.

    While they can't find certain kinds of bugs they can be helpful in finding other things.  It's all about how you are using them.  They are useful for testing out library things that you are going to be using in lots of clients as they can help you catch when an update changes the behavior, but they only make up the time it takes to write them if what you are testing is used all over the place.



  • So my suspicions are true! It's all meaningless (at least unit tests) and we should all live chaotically

    When I see immensely bad code I start to question my existence in the workforce and wonder if my profession is real. Guess that feeling only happens to me.



  • @OhNoDevelopment said:

    So my suspicions are true! It's all meaningless (at least unit tests) and we should all live chaotically
     

    Try a controlled test: one group do unit testing, another omit it completely. Compare the results.



  • @OhNoDevelopment said:

    What's really wrong with stringly-typed code?

    Stringly typed code is evil! (Or eval...) Just ask any ex-Perl programmer...


  • ♿ (Parody)

    @locallunatic said:

    While they can't find certain kinds of bugs they can be helpful in finding other things.  It's all about how you are using them.  They are useful for testing out library things that you are going to be using in lots of clients as they can help you catch when an update changes the behavior, but they only make up the time it takes to write them if what you are testing is used all over the place.

    What they're best for is catching regressions (which is sort of what you're talking about). And for catching them early, assuming you're actually running the tests, not just writing them. A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.



  • @boomzilla said:

    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.



  • @ekolis said:

    @OhNoDevelopment said:
    What's really wrong with stringly-typed code?

    Stringly typed code is evil! (Or eval...) Just ask any ex-Perl programmer...

    "nanosecond" != "nanosecond"

    "Scientology" == "potato"


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.

    Yuh-huh.



  • @boomzilla said:

    @blakeyrat said:
    @boomzilla said:
    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.

    Yuh-huh.

     

    ... unless the application is a Apple mapping application on iOS6, in which case the users won't accept there's anything wrong with it...

    /troll



  • @boomzilla said:

    @blakeyrat said:
    @boomzilla said:
    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.

    Yuh-huh.

    The interface is the application. It's impossible to have a "good" application with a bad interface.



  •  @blakeyrat said:

    @boomzilla said:
    @blakeyrat said:
    @boomzilla said:
    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.

    Yuh-huh.

    The interface is the application. It's impossible to have a "good" application with a bad interface.

    Boomy meant that when you have this good application that's in version $lots and suddenly something that's always worked since the fucking beta of 1.0 makes the application crash because of some stupid regression that someone half-implemented.

    Both that, and a fucked-up brand new fresh yippee UI will equally demolish your user's confidence in your application.


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    @blakeyrat said:
    @boomzilla said:
    A regression on a part of the application that's been stable for a while makes you look worse in the eyes of the users than a buggy new interface.

    Nuh-uh.

    Yuh-huh.

    The interface is the application. It's impossible to have a "good" application with a bad interface.

    Aside from the "Yuh-huh" bit, did you read what I wrote? Because your quote here makes it look like you didn't.



  • @dhromed said:

    Boomy meant that when you have this good application that's in version $lots and suddenly something that's always worked since the fucking beta of 1.0 makes the application crash because of some stupid regression that someone half-implemented.

    You could just say "Adobe Creative Suite."

    @dhromed said:

    Both that, and a fucked-up brand new fresh yippee UI will equally demolish your user's confidence in your application.

    Only if the "brand new fresh yippee" is bad. Like, say, ... Adobe Creative Suite. Again.

    But the real point I'm trying to make is that the interface is the application. Too many programmers don't get that. Saying "it works but it's hard to use" is the same thing as saying "it doesn't work."



  • @blakeyrat said:

    Saying "it works but it's hard to use" is the same thing as saying "it doesn't work."
     

    Saying "it's easy to use but it doesn't work"  is also the same thing as saying "it doesn't work."



  •  @Cassidy said:

    @OhNoDevelopment said:
    So my suspicions are true! It's all meaningless (at least unit tests) and we should all live chaotically


    Try a controlled test: one group do unit testing, another omit it completely. Compare the results.


    Did such a test about ten years ago for a company that was investigating whether they should go agile or not. The result was spectacular. (1) The unit-testing group took much longer to deliver and (2) their deliverables had much more bugs.

    The explanation was simple. (1) They wrote twice as much code. (2) They first wrote the test and than the code to pass the test. The quality was entirely determined by quality of the test samples and use cases. The other group had to judge the code by its own merit, mathematically proving its correctness (if only in their heads) and were thus able to discover and deal with much more boundary cases that the code revealed but the use cases and requirements did not.



  • @JvdL said:

    @blakeyrat said:
    Saying "it works but it's hard to use" is the same thing as saying "it doesn't work."
    Saying "it's easy to use but it doesn't work" is also the same thing as saying "it doesn't work."

    If it doesn't work then it's not easy to use, it's impossible to use.


  • ♿ (Parody)

    @blakeyrat said:

    But the real point I'm trying to make is that the interface is the application. Too many programmers don't get that. Saying "it works but it's hard to use" is the same thing as saying "it doesn't work."

    No, "it works but it's hard to use" is definitely better than "it's easy to use but it doesn't work." It's not good. But it's better. For instance, suppose Visual Studio started compiling increment operations as decrement operations. No interface change. Or a music player that adds static over the music when playing. A spreadsheet that multiplies wrong.

    I'm not downplaying the importance of a good interface at all. But if all you have is an interface, what is the point of the application?



  • @JvdL said:

    Saying "it's easy to use but it doesn't work"  is also the same thing as saying "it doesn't work."
     

    True.

    @blakeyrat said:

    Saying "it works but it's hard to use" is the same thing as saying "for me, it doesn't work. It may for you."
     

    FTFY. I believe there's a difference between "I can't get it to work" and "it's non-working". The latter suggests that trying to get it working is definitely a futile effort.



  • @JvdL said:

    Did such a test about ten years ago for a company that was investigating whether they should go agile or not. The result was spectacular. (1) The unit-testing group took much longer to deliver and (2) their deliverables had much more bugs.
     

    Ouch. Sounds like one in the eye for Agile, but it still sounds like the second group are still performing unit tests - just not formally.


Log in to reply