• (cs)

    Am I the only one who had the strong feeling that this story is really special somehow?

    After a lot of pondering, I now know what's so striking about it: Those people have working code!

    I mean - lucky Ben does not have to dig through the ugliest of all codes, he does not even have to do a lot of maintenance, that sounds like really nice code!

    Other facts that are quite uncommon here on theDailyWTF:

    • A job interview that does not last long, but not because of some dumb-ass candidate or interviewer!
    • A project leader who can actually answer the question what the purpose of a single code statement is, even immediately!

    TRWTF is that today, there is none.

  • al (unregistered)

    int = -2^16 to 2^16 (-1) 100000 > 2^16

  • BeerWineLiquor (unregistered) in reply to Benjamin Normoyle

    I thought it meant rewriting 80% of the shitty outsourced code by the 20% of original staff left with jobs...

  • Fedaykin (unregistered)

    A lot of what is sorta ETF in here is really just a perversion of good practices.

    Padding a time estimate is always the best option. Being able to go to a client/boss and say "Hey, we got done early!" is a lot better than "oh shit, we need more time!". The problem, of course, is the extreme abuse of this.

    KIRK: Scotty, "Do you always multiply your repair estimates by a factor of four?"

    SCOTTY: "How else to maintain my reputation as a miracle worker?"

  • (cs) in reply to Sean
    Sean:
    An int is 32 bits on a 32bit machine. The 386 came out in 1985, it's very likely that in 1990 they were using 386s and not 286s... therefore it's not an overflow caused by a 16bit int.

    But the first mainstream 32-bit* OS (for PCs) didn't arrive until 1995. Up until them 386's (and 486's) spent the vast majority of their time emulating slightly improved 286's.

    *Windows 95 was more of a 16/32-bit hybrid, but it ran 16-bit code in V86 mode, meaning that the processor spent most of it's time in a mode that was at least partially 32-bit.

  • Joon (unregistered) in reply to Tyler
    Tyler:
    Wayne is a goddamn genius.

    I do something similar at by giving out really long timelines for development and then consistently beating them by huge margins. This also gives me the benefit of extra time if something needs more work than I planned.

    I hate to break it to you, but any competent project manager would have realized long ago that you over-estimate ridiculously, and would not take that into account when planning entire projects

  • OnlyMe (unregistered)

    Where I used to work we used to joke doing this very thing!

  • Chmeee (unregistered)

    GCC will not optimize away the empty loop. It is documented as such, because GCC assumes that such a loop is purely for delay purposes, so optimizing it away is undesirable.

  • (cs) in reply to Carnildo
    Carnildo:
    Spectre:
    An int is what the compiler defines it to be. The only guarantee is that int can represent numbers from -32767 to +32767.

    Only if you're using C++ or a recent version of the C standard. The original guarantee is that:

    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

    with additional guarantees of

    sizeof(void *) == sizeof(int) sizeof(unsigned x) == sizeof(signed x)

    and that a char is large enough to store a single text character in the platform's preferred text encoding. On a machine using 7-bit ASCII, you could theoretically have an int with a range of -64 to 63.

    You're right, I looked it up in C99. But the point is still true, isn't it?

  • Eric M (unregistered)

    80/20 Rule, otherwise known as the Pareto Principle: http://en.wikipedia.org/wiki/Pareto_principle

    Interesting take on job security. Of course now-a-days, I don't think you could find a programming job in the US that you're not on a team that is completely understaffed for the project or projects it has.

  • (cs)

    The real WTF is.... that there is no WTF, this guy is a genius!

  • (cs) in reply to Zylon
    Zylon:
    The example that "Wayne" gives appears to be a mangling of Westheimer's Rule:
    To estimate the time it takes to do a task: estimate the time you think it should take, multiply by 2, and change the unit of measure to the next highest unit. Thus we allocate 2 days for a one hour task.

    That would be great:

    A: Hey how long does it take to count to 10 seconds? B: Oh, about 20 minutes, why?

  • Edward Royce (unregistered)

    Hmmmm.

    This is why I always include something very obviously wrong in the UI of any application I'm trying to get accepted by management. For some odd reason management types simply cannot accept a program as-is. Instead they all absolutely must make some sort of change to the program or else the program simply isn't "theirs".

    So I include obvious UI defects that they can easily see and order changed. Otherwise they'll really muck up a program and make life a lot harder.

  • Jon (unregistered) in reply to gcc4ef3r
    gcc4ef3r:
    uh, wouldn't the compiler optimize that away? i mean, depending on the intelligence of the compiler...
    GCC, for example, deliberately doesn't optimise away empty loops. The only reason someone would write an empty loop is to introduce a delay.
  • (cs) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    This is why I always include something very obviously wrong in the UI of any application I'm trying to get accepted by management. For some odd reason management types simply cannot accept a program as-is. Instead they all absolutely must make some sort of change to the program or else the program simply isn't "theirs".

    Unless, of course, the "app" is just a cheap mock-up. Then management is immediately convinced the product is perfect-as-is and ready to ship, regardless of how buggy and unstable you try to convince them it is.

  • dextron (unregistered)

    The Real WTF:

    Why was he in such a giant hurry to hire this fellow, when things were so...calm.

    Captcha: oppeto, Pinocchio's little sapling?

  • (cs) in reply to Jason
    Jason:
    When performing an AJAX operation that saves data, for example, users tends to disbelieve that it could have possibly saved in such a short amount of time. The calls tend to be almost instant. Thus, they'll click several times just "to make sure."
    1. Onclick you disable the button so they can't hammer on it.
    2. Show an animation if you wish.
    3. Show a "YOUR REQUEST SUCCEEDED, CONGRATULATIONS!!!" message.
    4. Re-enable the button.
  • (cs) in reply to Office Space
    Office Space:
    Isn't Initech the name of the company in the movie Office Space?

    No.

  • (cs) in reply to Zylon
    Zylon:
    swei:
    The 80/20 rule is a hypothesis (or idiom, not sure what to call it) that 20% of your software bug will take up 80% of your time. Or something like that.
    I swear to god, I must be posting in INVISIBLE MODE or something.

    Now calm down, friend. It's not you. Everyone else seems to be posting in TLDR mode (default on /.). I've read about three or four different comments ten times over when reading the posts here.

  • Robert Watkins (unregistered) in reply to Rene

    I'm not a DOS guy, but wouldn't it default to a signed short - ie MAX_INT will be 0XEFFF (2^15 - 1)?

  • Robert (unregistered) in reply to Benjamin Normoyle
    Benjamin Normoyle:
    I thought 80/20 was how to completely bullshit situations: when you need a percentage, use either 80 or 20 percent as your number.

    No, the 80/20 rule is that 80% of your resources will be consumed by 20% of the project. Or, 80% of your sales will come from 20% of your products. Etc.

  • (cs) in reply to Benjamin Normoyle

    80/20 rule.

    The first 80% of the project takes 80% of the time. The Last 20% of the project takes the other 80% of the time.

    Unless it's a TCP/IP port allocation scheme involving the universal firewall hole, and the HMP port.

    Ex

  • AcidBlues (unregistered) in reply to sweavo

    This is NOT a WTF. This is actually one of the most beatiful, creative and intelligent way for techies to manage higher levels.

    This should be put on a poster on all the office walls. Would remind managers that they are essentially inept at understanding developers and that the most important thing they need to build with its team is trust.

  • (cs) in reply to Teh Optermizar
    notromda:
    Tann San:
    I had a uni lecturer explain how we should do things like this. He said it was great as a contractor as he'd get calls back from past clients asking if he could update their system to run faster, he'd do the same thing as the OP said; shorten some un-necessary purposefully placed loop, say it took 6+ hours doing it and voila, instant pay day.

    Wow. See, this is why computer science needs a professional "engineering" association, which includes ethics in the prerequisites. It exists in other fields, why not in computer programming?

    Virginia Tech had a required "professionalism in computing" class that was supposed to cover that.. but it was more focused on ettiquette lessons like "'Business casual' dress code does not include sweatpants".

  • (cs) in reply to Joon
    Joon:
    Tyler:
    Wayne is a goddamn genius.

    I do something similar at by giving out really long timelines for development and then consistently beating them by huge margins. This also gives me the benefit of extra time if something needs more work than I planned.

    I hate to break it to you, but any competent project manager would have realized long ago that you over-estimate ridiculously, and would not take that into account when planning entire projects

    It's a circular argument. Everybody else on the team overestimates, so they assume you do to. Say it'll take 2 weekss? They think it'll take 5 minutes, and will therefore allocate 3 minutes to the project plan.

    The worst is when they have a fixed deadline without enough time allocated to get it done, then they ask you for estimates. "Well, I'll either have it done by Thursday or I won't be working here anymore, so I'd say Thursday is my estimate. Now you wanna stop wasting my time so I can get back to work?"

  • Peter (unregistered) in reply to Benjamin Normoyle

    80/20 is the pareto rule.

    http://en.wikipedia.org/wiki/Pareto_principle

  • (cs) in reply to Jon
    Jon:
    GCC, for example, deliberately doesn't optimise away empty loops. The only reason someone would write an empty loop is to introduce a delay.

    Not quite. For example:

    for (i = 0; i < gazillion; ++i)
{
#ifdef WEIRD_MACRO
  /* Do weird stuff */
#endif
#ifdef EVEN_WEIRDER_MACRO
  /* Do even weirder stuff */
#endif
}

    If I don't define any weird macros then the loop is useless.

    If you want busy wait, just use the volatile modifier.

  • Toby (unregistered) in reply to sweavo

    I was always told that 80/20 rule means that in any given project the first 80% of the work only takes 20% of the time. It takes a lot longer to do that last 20% of the work that gets the project working at 100%

  • AdT (unregistered) in reply to SomeCoder
    SomeCoder:
    The point was not that the loop was infinite; it was that the loop did nothing. Consider:

    someThreadVariable = 400;

    while (someThreadVariable != 500);

    DeleteAllFilesInUsersHomeDir();

    If we aren't careful with threading, someThreadVariable could be changed by another thread. So the current thread should "pause" until the other thread changes the variable to 500.

    If you run this in debug mode, it will work as you would expect. If you turn on optimizations, Visual Studio will see this as a loop that does nothing and remove it and the "pause" that we would expect is gone.

    I disagree. This loop does not "do nothing" - it prevents the execution of the code following it until some condition is met. In this case, the condition is !(someThreadVariable != 500), or someThreadVariable == 500 for short. If Visual C++ removes the loop in Release configuration, this breaks the semantics.

    Others have - incorrectly - claimed that the compiler may do this because someThreadVariable is not volatile. The lack of volatile allows the compiler to make assumptions about the state of someThreadVariable in the absence of threads, interrupts or other sorts of state change not effected by local code flow (in one word: asynchronous change). But in the case of your example, this only means that the compiler may replace the loop condition by "true", turning the loop into an infinite loop as without asynchronous changes of someThreadVariable, the condition will always be true.

    Changing the loop condition to "false", which is equivalent to what Visual C++ does, is, however, invalid with or without a volatile qualifier on someThreadVariable.

  • _js_ (unregistered) in reply to phaedrus
    phaedrus:
    swei:
    The 80/20 rule is a hypothesis (or idiom, not sure what to call it) that 20% of your software bug will take up 80% of your time. Or something like that.

    Now calm down, friend. It's not you. Everyone else seems to be posting in TLDR mode (default on /.). I've read about three or four different comments ten times over when reading the posts here.

    Why tell him to calm down? He didn't seem particularly upset...

  • Vilfredo Pareto (unregistered) in reply to Benjamin Normoyle

    No bull shit, it's how everything in the world is distributed, from water in drops (80% of the water is in 20% of the drops), to income distribution, customers (20% of your clients probably generate 80% of your profit) etc....

    http://en.wikipedia.org/wiki/Pareto_principle

  • schnitzi (unregistered) in reply to gcc4ef3r

    I would be very surprised if there was a compiler in the world that does that optimization. Lots of people use loops like that for delays. It would be a big presumption on the part of the compiler to disallow it.

    Not only that, the loop changes the value of i.

  • (cs) in reply to _js_
    _js_:
    phaedrus:
    swei:
    The 80/20 rule is a hypothesis (or idiom, not sure what to call it) that 20% of your software bug will take up 80% of your time. Or something like that.

    Now calm down, friend. It's not you. Everyone else seems to be posting in TLDR mode (default on /.). I've read about three or four different comments ten times over when reading the posts here.

    Why tell him to calm down? He didn't seem particularly upset...

    Damn. I concede.

  • Kneo (unregistered) in reply to Benjamin Normoyle

    The 80/20 rule applies like this: 80% of the profit in my store comes from 20% of the items sold. 80% of the work done with my app excercises 20% of the code. 80% of the population owns 20% of the wealth. In most companies 80% of the work is done by 20% of the staff...

  • [ICR] (unregistered)

    afaik Java is one of the only language to do the sort of loop optimisation where you remove "ineffective" loops and even then it doesn't do it anymore.

    And the .NET comparison isn't really correct, because a lot of optimisation goes on in the JIT compiler (as Java's did in this case). All you're doing is comparing the CIL which is only half optimised.

  • (cs) in reply to Alcari
    Alcari:
    Oh, i've done that. Someone complained that sometimes, saving a file was to fast, so he didn't know if it was succesfull, since the statusbar popped in and out to fast.

    Solution: If filesize < 2mb open FakeSaveAnimation.gif end

    There is an ENORMOUS difference between slowing things down for the sake of making you and your department look better, and slowing things down to let the user know something happened.

  • tikva (unregistered) in reply to Carnildo
    Carnildo:
    with additional guarantees of

    sizeof(void *) == sizeof(int)

    You must be kidding...

  • Zygo (unregistered) in reply to Chmeee
    Chmeee:
    GCC will not optimize away the empty loop. It is documented as such, because GCC assumes that such a loop is purely for delay purposes, so optimizing it away is undesirable.

    GCC 4.1 (and possibly earlier versions) does optimize away loops which can be proven to have no side effects visible to standard-compliant programs from outside of the loop. This can remove significantly non-empty loops if the compiler can prove the optimization has no semantic effects visible from within the program but outside the loop (obviously the optimizer doesn't take into account execution time, heat and EMI from the CPU, etc so any such effects will be lost).

    I found this out the hard way when trying to compare the execution time of various algorithms for calculating a simple idempotent function by calling the function millions of times in a loop. Unless I dereferenced a pointer within the function, the optimizer would determine that it was necessary to call the function at most once, ruining my test.

  • Zygo (unregistered) in reply to Zygo
    Zygo:
    GCC 4.1 (and possibly earlier versions) does optimize away loops...

    ...if used with -O2 (maybe -O1 as well). Without a -O flag, or with -O0, GCC won't do any optimizations at all, not even trivial ones.

  • Doug Jones (unregistered)

    There's something fiendishly brilliant about it... >:)

  • eric76 (unregistered) in reply to Tyler
    Tyler:
    Wayne is a goddamn genius.

    I do something similar at by giving out really long timelines for development and then consistently beating them by huge margins. This also gives me the benefit of extra time if something needs more work than I planned.

    Years ago, working for an engineering company, my boss went into detail about something he wanted done and how he wanted me to do it. He then asked me how long it would take. I thought about it and said that it would take about two weeks.

    That evening after he left, I thought of another approach to solving the problem that would accomplish the same thing but was substantially simpler to program. So I went ahead and did it. It took about an hour or two to finish using this approach.

    The next day, my boss came up to me and told me to go ahead and do it. He was a bit ticked off when I told him I finished it the night before and explained the way I did it.

    I think he waited two weeks to show the results to his boss.

  • (cs) in reply to chrismcb
    chrismcb:
    Alcari:
    Oh, i've done that. Someone complained that sometimes, saving a file was to fast, so he didn't know if it was succesfull, since the statusbar popped in and out to fast.

    Solution: If filesize < 2mb open FakeSaveAnimation.gif end

    There is an ENORMOUS difference between slowing things down for the sake of making you and your department look better, and slowing things down to let the user know something happened.

    I agree with you, to be truly ethical such loops (without another purpose like synchronisation, interfacing with a human, etc) shouldn't be used as a general rule of thumb.

    On the other hand, if your boss is milestone minded and only pays attention to say runtime (or other very small minded and limited statistics) techniques like the above can be useful to show that progress is being made. To be ethical in this case you actually need to have made progress with program faults/refactoring/scaffolding.

    It would also be useful in punishing your bosses for a really crappy design decision, you can simply slow the program down.

    boss: Why is the system so slow? tech: Well you know those changes to the xyz runtime... boss: yes? tech: They don't fit there, we need to move them to abc (the right place) boss: Will that speed it all up again? tech: Pretty sure.

    (Note: you really only should punish them, if you are very certain it won't work/work well. You shouldn't use it when your simply not getting your way, doing something your uncertain of/don't want to do)

    Sometimes you need to get people to respect your knowledge and skill. Sometimes you can only do it by hitting them - even though we don't really want to. , it's the difference between being paid to make a crappy house, and being paid to make the house they really will like and need.

  • Amanda (unregistered) in reply to notromda

    Well, I don't know how common this is, but I'm majoring in Computer Science and at my university we're in the College of Engineering. Second semester senior year, we're required to take an Ethics course.

  • chrome (unregistered)

    I've read the discussion on whether or not an empty loop would be optimised away by a modern compiler, but surely a loop such as

    for (i=0; i<10; i++) {;}

    would be optimised to NOP x 10 by most compilers set to 'unroll loops'? And would they then remove redundant NOPs?

    (10 minutes passes)

    Well, after some testing, it seems that gcc won't optimise out loops like this, but Sun Workshop cc (also known as Sun Pro cc) WILL optimise out loops like this with -fast.

    I guess the thing is, if you're inserting bogus delay code to make yourself look better a few months down the line when you 'optimise' the code, use usleep(). :)

  • lgh (unregistered) in reply to sweavo

    um, the story takes place in 1990. November 1989, plus ~(3) months, makes it ~February 1990. :-)

  • schmilblick (unregistered)

    Speed-up loop. It's.... it's... insurance, and pure genious!

  • MS (unregistered) in reply to Crash Magnet
    Crash Magnet:
    I thought the 80/20 rule was: The first 80% of the project take 20% of your time, the last 20% of the project takes 80% of the time. But I remember it as the 90/10 rule.
    I think you mixed them up. The 80/20 says that 80% most useful functionality takes only 20% of the total implementation effort, so you better convince your customer to drop the rest. The 90/10 says that implementing 90% of the system takes 90% of the planned implementation time, but the remaining 10% takes another 90% planned time :-P
  • iMalc (unregistered)

    Assuming that i is an int (-32768 .. 32767), then thanks to integer overflow, when they drop the first zero off that they'd blow all their future speedup ability in one hit. 100000 is 0x186A0 in hex, which will get stored as 0x86A0, which as a signed int just happens to be negative since the high-bit is set. So, since zero is not less than a negative number, the loop will terminate immediately.

    Then they'd have to do some real optimisation work next time!

  • (cs)

    Someone wrote "xor eax, eax" instead of "mov eax, 0". Damn, I love it. You save a cycle!

  • Marcus (unregistered)

    I love the idea of Windows 2.11, having worked at Philips on a add on toolset for Windows 2, that was released a month before Windows 3 made it obselete by implementing all the features we had carefully crafted to get round the limitations that were no longer there.

Leave a comment on “The Speed-up Loop”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article