• nitePhyyre (unregistered)

    *And yes, that includes 2 girls 1 cup

  • WantedToTrollButLostWillToLive (unregistered)

    But I can't even be bothered to do that. They've already been told anyway.

  • Fritz, a.k.a. Fritzo (unregistered)

    They should just change the subtitle to "Banal Perversions in Story-Writing".

  • QJo (unregistered) in reply to Fritz, a.k.a. Fritzo
    Fritz:
    Mike:
    I don't know guys, if you are all so unhappy with the stories why don't you just ask for your money back?

    This site to me is an enjoyable 5 min visit, what is it to you?

    Oh hey Mike... OR SHOULD I SAY ALEX?!

    It would disappoint me, but not surprise me, if the TDWTF staff decided to shut the site down as a result of all this egregious flaming. Simple answer: delete all those whining comments about how subjectively bad they think it is, and equally delete with extreme prejudice those even whinier subsequent comments complaining about censorship. If those readers don't like the site, then flush them down the proverbial toilet.

  • Jainee (unregistered) in reply to faoileag

    Pfft. Политбюро. Here, fixed it for everyone.

  • faoileag (unregistered) in reply to QJo
    QJo:
    Simple answer: delete all those whining comments about how subjectively bad they think it is, and equally delete with extreme prejudice those even whinier subsequent comments complaining about censorship. If those readers don't like the site, then flush them down the proverbial toilet.
    So, if the users of a product start complaining about the declining quality of the product, or are unhappy about the performance of some people creating the product, your solution is to silence the users.

    Nice business model.

    To put it in another context: if you run a restaurant with a complaints box that sees a steady return of complaints, you could address each one of them.

    Or you could remove the complaints box and stop handing out a standardized feedback form.

    Whatever solution is better for your business I leave up to you to figure out.

  • Scourge of Programmers! (unregistered)

    how exactly does windows registry work for passing values between computers?

    One confused programmer

  • (cs) in reply to Dogsworth
    Dogsworth:
    no laughing matter:
    Rather good WTF ruined by story-embellishment!

    Fire that Erik Gern, he won't stop destroying WTFs by his story-writing!

    Yeah, he's by far the worst. It's great that he thinks he's a wonderful fiction writer, but it ruins the WTFs by making everything ridiculous.

    Could we blue this, please?

  • (cs) in reply to Scourge of Programmers!
    Scourge of Programmers!:
    how exactly does windows registry work for passing values between computers?

    One confused programmer

    same way one would use a file: one process writes to known values and the other reads them back

  • ih8u (unregistered) in reply to NamingException
    NamingException:
    Dogsworth:
    no laughing matter:
    Rather good WTF ruined by story-embellishment!

    Fire that Erik Gern, he won't stop destroying WTFs by his story-writing!

    Yeah, he's by far the worst. It's great that he thinks he's a wonderful fiction writer, but it ruins the WTFs by making everything ridiculous.

    Could we blue this, please?

    Agreed. Story embellishment can be a beautiful thing; it can add further interest through proper storytelling, and a bare bones WTF explanation can become a dramatic story that begs retelling. (hay did you see tdwtf? let me tell you about today's article)

    Erik, embellishment is not just adding words. I appreciate the analogy to the Cold War, showing the stark division between dev teams. The shared space sucks because neither team will even talk -- much less cooperate to make their lives better. But please, don't just add words. You're not filling a page of a newspaper.

  • Chris V (unregistered)

    Like others have mentioned, this had the makings of a good WTF story, but the embellishment was ridiculous. I like WTF stories for the WTFs, not the writing.

  • foo AKA fooo (unregistered)

    No moon race, no Cuba crisis, no nuclear overkill, no Vietnam of Afghanistan?

    I think the embellishment hasn't gone far enough. I expect more from Erik next time.

  • MrBester (unregistered)

    "She wore a severe, Soviet-style pantsuit with red trim" Gonna need a picture for that. I have no idea what would be described as a "Soviet-style" pantsuit apart from the one Brigitte Nielsen wore in Rocky 4. I'm guessing it didn't look like that...

  • Foggen (unregistered)

    Idiotic embellishments ruin what is meant to be credible if startling stories. If the entire thing is ridiculous, why should we be surprised when somebody does something dumb?

  • OldCoder (unregistered) in reply to faoileag
    faoileag:
    QJo:
    Simple answer: delete all those whining comments about how subjectively bad they think it is, and equally delete with extreme prejudice those even whinier subsequent comments complaining about censorship. If those readers don't like the site, then flush them down the proverbial toilet.
    So, if the users of a product start complaining about the declining quality of the product, or are unhappy about the performance of some people creating the product, your solution is to silence the users.

    Nice business model.

    To put it in another context: if you run a restaurant with a complaints box that sees a steady return of complaints, you could address each one of them.

    Or you could remove the complaints box and stop handing out a standardized feedback form.

    Whatever solution is better for your business I leave up to you to figure out.

    Works for the Chinese Government...

  • Valued Service (unregistered)

    If this was curious perversions in technology, all I needed to know was the method of communication.

    Via the registry.

    Amazing. blinks

    I don't care what divided the company.

    Here's my version.

    "I work at this company where there are two departments working on different aspects of the software. There's a divide between the departments because one uses C++ and the other C#. They each have this superiority complex over the other.

    So, while working on my project to expand phone numbers to include the global code instead of just 10 digits, I decided to peek at the way communication is handled.

    The products communicate through the OS registry!

    When I mentioned to my superiors that this could end up corrupting the registry and ruining someone's machine due to any number of reasons (race conditions, etc), they seemed disinterested.

    When I submitted changes on both sides to use interprocess pipe, they revoke the change and threatened disciplinary action."

  • NeedsMoreColdWar (unregistered) in reply to Valued Service
    Valued Service:
    "I work at this company where there are two departments working on different aspects of the software. There's a divide between the departments because one uses C++ and the other C#. They each have this superiority complex over the other.

    So, while working on my project to expand phone numbers to include the global code instead of just 10 digits, I decided to peek at the way communication is handled.

    The products communicate through the OS registry!

    When I mentioned to my superiors that this could end up corrupting the registry and ruining someone's machine due to any number of reasons (race conditions, etc), they seemed disinterested.

    When I submitted changes on both sides to use interprocess pipe, they revoke the change and threatened disciplinary action."

    Needs more cold war.

  • Anonymous Coward (unregistered) in reply to neminem
    neminem:
    No, this was still better than a Hanzo article. After all, there was at least a real, believeable, WTF or two hidden under all the stupid, boring fakery. But there was also quite a lot of that.

    Note: we don't come here to read bad fiction. We come here to read real WTFs. We accept anonymization, that doesn't mean we accept stories that were clearly anonymized so much that they turn into stupid sitcoms.

    All it needs is an a capella intro theme and a wacky neighbor.

  • neminem (unregistered) in reply to ih8u
    ih8u:
    Erik, embellishment is not just adding words. I appreciate the analogy to the Cold War, showing the stark division between dev teams. The shared space sucks because neither team will even talk -- much less cooperate to make their lives better. But please, don't just add words. You're not filling a page of a newspaper.
    Agreed. I don't mind saying that something was *like* the cold war, even making jokes about it being the cold war. But saying that you literally walked into one office and they were like "GO COMMUNISM", and you walked into the other office and they were playing the national anthem and saluting an eagle, that's not funny anymore. No, they were clearly not actually doing those things. That has nothing to do with programming.
  • Raph (unregistered)

    Well, you know what ? I found the story rather entertaining, and the angle was well-exploited.

    Haters gonna hate !

  • FreeMarketFan (unregistered) in reply to Peter

    If you don't have a good article to post - just don't post anything. Please.

    This was just trash. Pure trash

    CAPTCHA: populus - the populus demanded that this crap never see the front page again

  • (cs)

    Apparently the author also doesn't know what happened to Trotsky.

    Also, In Soviet Russia, API is PAI. (joke fail)

  • Fritz, a.k.a. Fritzo (unregistered) in reply to QJo
    QJo:
    Fritz:
    Mike:
    I don't know guys, if you are all so unhappy with the stories why don't you just ask for your money back?

    This site to me is an enjoyable 5 min visit, what is it to you?

    Oh hey Mike... OR SHOULD I SAY ALEX?!

    It would disappoint me, but not surprise me, if the TDWTF staff decided to shut the site down as a result of all this egregious flaming. Simple answer: delete all those whining comments about how subjectively bad they think it is, and equally delete with extreme prejudice those even whinier subsequent comments complaining about censorship. If those readers don't like the site, then flush them down the proverbial toilet.

    Oh wow you're completely clueless. People 'whining' is the most entertaining stuff on this site (which reminds me: bring back Mandatory Fun Day) and you want to take it away?

  • (cs)

    The story embellishment is a problem when it gets in the way of the story.

    Reading the story should make us readers want to write snappy comments about the WTF. This often gets pretty lively and entertaining. Commenters might have surprising takes on the politics, interesting elucidations of the technologies, or even their own related stories to tell.

    A badly written story suppresses that. It distracts us with unnecessary dialog and plot, misspellings, bad grammar, typos, misused words, and characters whose names and/or genders change in mid-paragraph. The writer fails at what writers should do.

    A badly written story makes us readers want to comment about the writing WTF instead of the IT WTF.

  • (cs)

    In Soviet Russia, libraries GAC you!

  • (cs) in reply to nitePhyyre
    nitePhyyre:
    faoileag:
    This is 2014 and I said I was mistaken in assuming the method was "innovative". Because Microsoft acknowledged the method way back in 2006. What's your problem?
    Reading comprehension, clearly.

    In addition to adding another This Iron Curtain embellishment was the worst thing to ever waste my bandwidth*" to the chorus, why the hell was one of the subheaders "Stalinist SVN" when that section never even came close to thinking about mentioning version control?

    Fire this loser.

    I was equally confused about that. "Tariq thought as he checked out the IPC API." must be a very veiled attempt at a reference to source control, as written on various mood altering substances.

  • (cs) in reply to faoileag
    faoileag:
    I don't know. This part of the story looks completely made by someone who doesn't seem to know very much about programming.

    I wouldn't say that they don't know much about programming, so much as that they don't know much about the business world.

    When it comes to projects, the business owners don't care about how you get it done, they just care that you get it done within budgetary and time constraints. If you want to rewrite an API, they won't give you the budget or resources for that. They just want to make sure that they get what they need, and it's up to you to make sure that it doesn't break, but doesn't take too long to develop.

    When it comes to systems that you did not develop, you have to go with the flow on small updates like this, and changing the architecture to fit a better model is a long-term project down the road, usually with little ROI for the business.

    For these projects, I generally just have the motto "leave things better than you found them." I improve the small parts where I can (I just recently made a change to encapsulate a piece of code that copy and pasted everywhere in an app, fitting the DRY principle), but only if they're quick and painless. It's very analagous to premature optimization: the more you change, the more likely you are to break something. So if it ain't break, don't fix it, just note that there's a better way to do it, and hope that that project eventually gets some notice.

  • Met (unregistered)

    If I hadn’t," Tariq said, "and either one of us screwed up a routine, a race condition could corrupt the Windows Registry. We’d have to have our support tech reinstall windows every time the registry corrupts on a user’s machine."

    This article is B.S.

    What method were they using to update the registry? How could a race condition cause you to have to reinstall Windows? If an app can corrupt the registry in a way that requires a reinstall of windows and not the app, virus writers need to start using this exploit so Microsoft will fix it.

  • whocares (unregistered) in reply to chubertdev
    chubertdev:
    faoileag:
    I don't know. This part of the story looks completely made by someone who doesn't seem to know very much about programming.

    I wouldn't say that they don't know much about programming, so much as that they don't know much about the business world.

    When it comes to projects, the business owners don't care about how you get it done, they just care that you get it done within budgetary and time constraints. If you want to rewrite an API, they won't give you the budget or resources for that. They just want to make sure that they get what they need, and it's up to you to make sure that it doesn't break, but doesn't take too long to develop.

    When it comes to systems that you did not develop, you have to go with the flow on small updates like this, and changing the architecture to fit a better model is a long-term project down the road, usually with little ROI for the business.

    For these projects, I generally just have the motto "leave things better than you found them." I improve the small parts where I can (I just recently made a change to encapsulate a piece of code that copy and pasted everywhere in an app, fitting the DRY principle), but only if they're quick and painless. It's very analagous to premature optimization: the more you change, the more likely you are to break something. So if it ain't break, don't fix it, just note that there's a better way to do it, and hope that that project eventually gets some notice.

    this.

    so many devs just don't get it. if you want to build a monument to computer science go work on (or start) some open-source project.

  • Tom (unregistered) in reply to Valued Service
    When I submitted changes on both sides to use interprocess pipe, they revoke the change and threatened disciplinary action

    MSMQ, sockets, pipes, COM components, an SQL database, or even drop files would be better than passing application data through the registry. A first year CS student should know better...

    Unfortunately, what happens all too often is that someone who works at a company in a job completely unrelated to IT taught himself some code in high school and "knows programming." He ends up hacking together some piece of junk, and then the company hires "real" programmers who are afraid to rock the boat. A decade later, every single member of the entrenched culture knows that the product is complete garbage, but not a single one is willing to speak up, because they like their paycheck more than their integrity.

    And so these WTF's are left as fuel for future horror stories.

  • trollfacenot (unregistered)

    Not every self-taught programmer fits your stereotype... I beg to differ. I find that most college educated IT "programmers" have a much harder time understanding the most basic fundamentals of programming.

    "Oh an object! I had a test on that once... let me see if I can remember... nope got drunk instead..."

  • Valued Service (unregistered) in reply to chubertdev
    chubertdev:
    faoileag:
    I don't know. This part of the story looks completely made by someone who doesn't seem to know very much about programming.

    I wouldn't say that they don't know much about programming, so much as that they don't know much about the business world.

    When it comes to projects, the business owners don't care about how you get it done, they just care that you get it done within budgetary and time constraints. If you want to rewrite an API, they won't give you the budget or resources for that. They just want to make sure that they get what they need, and it's up to you to make sure that it doesn't break, but doesn't take too long to develop.

    When it comes to systems that you did not develop, you have to go with the flow on small updates like this, and changing the architecture to fit a better model is a long-term project down the road, usually with little ROI for the business.

    For these projects, I generally just have the motto "leave things better than you found them." I improve the small parts where I can (I just recently made a change to encapsulate a piece of code that copy and pasted everywhere in an app, fitting the DRY principle), but only if they're quick and painless. It's very analagous to premature optimization: the more you change, the more likely you are to break something. So if it ain't break, don't fix it, just note that there's a better way to do it, and hope that that project eventually gets some notice.

    I disagree,

    Refactoring needs to be seen as regular maintenance.

    If you don't refactor, the tower gets taller and taller with less and less foundational support. It becomes a Jenga game, waiting for the point where a single change reveals a seesaw problem. (seesaw problem is where the only reasonable cost-to-benefit solutions have mutually exclusive bugs.)

    IMO, Refactoring has a BIG cost-benefit. It ensures the ability to continue to operate at full capacity regardless of software scale. And it allows for YAGNI to dominate design decisions.

    The longer you go without refactoring (when needed), the more effort every change requires. To the point where a 1 week project becomes a 1 month project.

  • Tom (unregistered) in reply to Met
    What method were they using to update the registry? How could a race condition cause you to have to reinstall Windows? If an app can corrupt the registry in a way that requires a reinstall of windows and not the app, virus writers need to start using this exploit so Microsoft will fix it.

    Well, here's a simple example: in order to keep multiple transactions from overwriting the same registry keys, the developers append an index value to the key name each time a transaction writes. So the key name might be "CALLDATA.003789" for this transaction.

    The code that posts the transaction has some error-retry logic. That error-retry logic is, basically, "reset and try the transaction again."

    There's an coding error in a recent checkin. It causes an excepting parsing a telephone number. The retry logic doesn't actually check the TYPE of exception thrown. Instead, it just reposts the transaction.

    20 minutes later, the post routine has written 2^32 records to the registry, filling up the entire hard drive and causing the server to grind to a screeching halt.

    At this point, Windows will not boot. There's no way to open the registry and clean out the affected records. Since the app is probably using the HKLM hive, you can't even just blow away the user's profile.

    Sure, you could use a live boot CD and NT Registry editor... but are you going to hand-delete 2 billion registry values?

  • Aris (unregistered)

    Still a better love story than twilight.

  • Valued Service (unregistered) in reply to whocares
    whocares:
    this.

    so many devs just don't get it. if you want to build a monument to computer science go work on (or start) some open-source project.

    No, business doesn't get it.

    Let's say you have a manufactoring plant. And your production is growing. But instead of investing in a heavy duty manufacturing machine that handles 1000s of items per minute and moving to a larger building, you simply add another small shop off of your current building, and throw in another machine that handles 100s ipm.

    • Next thing you know, you have major scaling problems.
    • You're having to constantly deliver materials to different sites to ensure all sites have proportionate supply.
    • You have to deliver your products from multiple sites.
    • You have more communication barriers.
    • As a owner/CEO, You have to visit more and more sites.
    • You have to hire more and more overhead.
    • You have to replace hardware failure more frequently.

    All these things add major overhead costs that slow down production more and more. And then you can't adapt as quickly to your competitors.

    All because of the marginal cost benefit of not upscaling.

    That's exactly what happens when you don't take the time to refactor.

  • (cs) in reply to Valued Service
    Valued Service:
    I disagree,

    Refactoring needs to be seen as regular maintenance.

    If you don't refactor, the tower gets taller and taller with less and less foundational support. It becomes a Jenga game, waiting for the point where a single change reveals a seesaw problem. (seesaw problem is where the only reasonable cost-to-benefit solutions have mutually exclusive bugs.)

    IMO, Refactoring has a BIG cost-benefit. It ensures the ability to continue to operate at full capacity regardless of software scale. And it allows for YAGNI to dominate design decisions.

    The longer you go without refactoring (when needed), the more effort every change requires. To the point where a 1 week project becomes a 1 month project.

    Well, that's part of what I'm saying. You pay off your technical debt. But you do it by improving what you touch, not changing everything at once. If something desperately needs to be refactored, then it should be logged as a defect. When estimating time on a project, there is usually the "X hours" for going with the way it is versus the "Y hours" for refactoring and then making the change on the improved code. Anyone sane should hope for the latter being faster, since it does result in an improved codebase.

  • Valued Service (unregistered) in reply to chubertdev
    chubertdev:
    Valued Service:
    I disagree,

    Refactoring needs to be seen as regular maintenance.

    If you don't refactor, the tower gets taller and taller with less and less foundational support. It becomes a Jenga game, waiting for the point where a single change reveals a seesaw problem. (seesaw problem is where the only reasonable cost-to-benefit solutions have mutually exclusive bugs.)

    IMO, Refactoring has a BIG cost-benefit. It ensures the ability to continue to operate at full capacity regardless of software scale. And it allows for YAGNI to dominate design decisions.

    The longer you go without refactoring (when needed), the more effort every change requires. To the point where a 1 week project becomes a 1 month project.

    Well, that's part of what I'm saying. You pay off your technical debt. But you do it by improving what you touch, not changing everything at once. If something desperately needs to be refactored, then it should be logged as a defect. When estimating time on a project, there is usually the "X hours" for going with the way it is versus the "Y hours" for refactoring and then making the change on the improved code. Anyone sane should hope for the latter being faster, since it does result in an improved codebase.

    How do you do that to a MFC business software suite?

    Sure, you can pull out modules at a time, but that's usually seen as new product dev.

    Sometimes you have to bite the bullet, and replace software.

  • (cs) in reply to Valued Service
    Valued Service:
    How do you do that to a MFC business software suite?

    Sure, you can pull out modules at a time, but that's usually seen as new product dev.

    Sometimes you have to bite the bullet, and replace software.

    If it's truly that bad, then the time to make each change should be astronomical compared to what it would be in a better system.

    Slightly separate scenario from the article, where it's something that "works" and is maintainable, but it's definitely the wrong way to do it.

  • (cs) in reply to OldCoder
    OldCoder:
    faoileag:
    So, if the users of a product start complaining about the declining quality of the product, or are unhappy about the performance of some people creating the product, your solution is to silence the users.

    Nice business model.

    To put it in another context: if you run a restaurant with a complaints box that sees a steady return of complaints, you could address each one of them.

    Or you could remove the complaints box and stop handing out a standardized feedback form.

    Whatever solution is better for your business I leave up to you to figure out.

    Works for the Chinese Government...
    But the American Government's procedure for complaint resolution works so much better:

    1. Read complaint (this step optional)
    2. Send form letter acknowledging complaint
    3. Throw away complaint
  • UR MOM (unregistered)

    HAHAHAAAAAAAAAAAAAAAAAAAAAA THIS ARTICLE SO GOOD QUALITY! GUARNTE TO 100% MORE FUNNY

  • (cs)

    I agree with the others complaining about the embellishment. I would much rather read the original submissions. I understand that they might have to be edited to remove/alter specific references that could result in legal action, but that is about all that should be changed.

    If anything should be added, it would be an explanation of the problem. Any given reader might not know the language(s) used or the ins and outs of the particular issue.

    Sincerely,

    Gene Wirchenko

  • Mike (unregistered) in reply to UR MOM
    UR MOM:
    HAHAHAAAAAAAAAAAAAAAAAAAAAA THIS ARTICLE SO GOOD QUALITY! GUARNTE TO 100% MORE FUNNY
    Here is your nickel!
  • (cs)

    For those unfamilar with communication via the registry in Windows proper (not compact), here is a little history on why it is a bad idea.

    In the early 2000s, Intuit used this method to communicate with add-ons in its QuickBooks product. Microsoft recommended strongly against doing the communication this way (the exact way that they were doing it) because it could cause security issues, and would be prevented in the future. Microsoft also made it so you could not pass their made for Windows certification like this.

    Intuit basically said they didn't care, and went ahead without the certification (a bigger deal then). Windows Vista was getting ready to be released and Intuit still didn't budge. Microsoft released Vista with the new security model and, guess what, it broke all compatibility that Quickbooks had with those plugins.

    Of course, who got the blame? Microsoft because this new version couldn't even run Quickbooks right.

    So, in the end... uhh... what was the moral of the story? Oh yeah, don't do it unless you are able to blame Microsoft for your bad code... something that some people have a talent for.

  • (cs)

    Apparently Wanda was dumped down a memory hole.

  • Sir Galahad the pure (unregistered) in reply to faoileag
    faoileag:

    To put it in another context: if you run a restaurant with a complaints box that sees a steady return of complaints, you could address each one of them.

    Or you could remove the complaints box and stop handing out a standardized feedback form.

    You could also wire the complaints box with enough sensors to a) detect whether the complaint is just "Your restrant sux0rz" or a sensible comment, and - depending on the former or latter - kick the user/complainer in their private parts with an automated boot-on-a-pole. Would be much more badass.

  • (cs) in reply to Sir Galahad the pure
    Sir Galahad the pure:
    faoileag:

    To put it in another context: if you run a restaurant with a complaints box that sees a steady return of complaints, you could address each one of them.

    Or you could remove the complaints box and stop handing out a standardized feedback form.

    You could also wire the complaints box with enough sensors to a) detect whether the complaint is just "Your restrant sux0rz" or a sensible comment, and - depending on the former or latter - kick the user/complainer in their private parts with an automated boot-on-a-pole. Would be much more badass.

    And by "wire", you obviously mean hire an intern.

  • blivet (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    If anything should be added, it would be an explanation of the problem. Any given reader might not know the language(s) used or the ins and outs of the particular issue.

    Agreed. Sometimes the entire article pretty much consists of "Get a load of this," followed by 300 lines of code.

  • (cs) in reply to blivet
    blivet:
    Gene Wirchenko:
    If anything should be added, it would be an explanation of the problem. Any given reader might not know the language(s) used or the ins and outs of the particular issue.

    Agreed. Sometimes the entire article pretty much consists of "Get a load of this," followed by 300 lines of code.

    That usually makes the comments more entertaining, and informative.

  • Dominic (unregistered)

    In soviet division, curtain irons you!

  • Jake (unregistered) in reply to nitePhyyre
    nitePhyyre:
    In addition to adding another This Iron Curtain embellishment was the worst thing to ever waste my bandwidth*" to the chorus, why the hell was one of the subheaders "Stalinist SVN" when that section never even came close to thinking about mentioning version control?

    But the entire story was about subversion! You know, in the actual English meaning of the word.

Leave a comment on “Process Communication Hell”

Log In or post as a guest

Replying to comment #:

« Return to Article