• beef (unregistered)

    First (to ask "huh?")

  • Whocares? (unregistered)

    The daily grandstand?

  • James (unregistered)

    I feel like this was "I hit submit it before finishing the story" thing.

  • Roburius (unregistered)

    I believe the "WTF" is that after putting in that monumental effort and getting everything basically right, the general reaction was "That wasn't so hard. What took you so long?"

  • Dude (unregistered)

    TRWTF is that there doesn't appear to be a WTF.

  • Anony (unregistered)

    I think Roburius is right, but the interesting post could have been written to stress that more.

  • (nodebb)

    That's a better ending then what happened to me a few years ago. Indian developers had developed a messaging library that only understood to put a single message in a transaction. Multiple messages meant multiple transactions with the queue system. For every possible combination of parameters, they had a separate function. Some functions could use some of the functionality of the messaging platform, others used other functionality. If you needed a new combination, some Indian would add a new function to their API of many of similar-but-not-exactly-the-same-functions. It was a mess. I solved the issues but separating transaction management from message management and refactor their API into a fluent API to allow free use of desired features. Then a junior spent a full month on ripping out the old library with the new one. I had promised a speed-up of x13 when PUTting messages in batches of 50. During test however, there was no improvement at all. Turns out that for this particular use case, the junior had re-created the original behavior too realistically by treating a single message in a single transaction. I investigated and fixed it within half an hour by just taking the transaction outside the loop over the messages. But it was too late. Upper management decided to roll back and now they are stuck with an inefficient messaging library. And I left for greener pastures.

  • (nodebb)

    That's a better ending then what happened to me a few years ago. Indian developers had developed a messaging library that only understood to put a single message in a transaction. Multiple messages meant multiple transactions with the queue system. For every possible combination of parameters, they had a separate function. Some functions could use some of the functionality of the messaging platform, others used other functionality. If you needed a new combination, some Indian would add a new function to their API of many of similar-but-not-exactly-the-same-functions. It was a mess. I solved the issues but separating transaction management from message management and refactor their API into a fluent API to allow free use of desired features. Then a junior spent a full month on ripping out the old library with the new one. I had promised a speed-up of x13 when PUTting messages in batches of 50. During test however, there was no improvement at all. Turns out that for this particular use case, the junior had re-created the original behavior too realistically by treating a single message in a single transaction. I investigated and fixed it within half an hour by just taking the transaction outside the loop over the messages. But it was too late. Upper management decided to roll back and now they are stuck with an inefficient messaging library. And I left for greener pastures.

  • djingis1 (unregistered) in reply to bjolling

    Sounds like a pretty good ending to me.

  • henk (unregistered)

    yet another "I am great" post by snoofle; get your own blog so it's easier to ignore please

  • Brian (unregistered)

    Here's my version of that story, which didn't end nearly so well. At a previous job, we had a rather demanding customer who wanted our product to do something that went far beyond what was originally designed to do. But they promised us a lot of money for it, so of course we took the job. My task was to convert part of our communication framework from an ancient proprietary system to something that would work in a more modern, distributed, RESTful fashion. This was to be a fundamental change to our platform that would open the door to great advances for the product. I spent months on development and testing until I had a nice elegant solution that worked as desired, fixed several of the problems of the old system, cut out tons of dead code, consolidated several disparate fragments of code into one coherent place, streamlined our process, etc. Then when it was finally ready to be merged, the architects (who had originally signed off on the project) decided it was too "risky" and made me shunt it off into a customer-specific feature that was only enabled for this one customer while everyone else would still use the old system. This of course led to mountains of technical debt, which, as far as I know, they're still paying for.

  • Chris L (unregistered)

    "It turns out that I missed 3 little bugs, but they were suffiently visible that it prevented the application from doing anything useful."

    If 3 bugs prevented the application from doing anything useful, I wouldn't describe them as "little".

  • Dave (unregistered) in reply to Chris L

    If you have a bug that e.g. you've forgotten to remove the line at the start of a config file that tells it to connect to the test DB, that's a trivial bug, but a show-stopper in production until you fix it.

  • Zenith (unregistered) in reply to Chris L

    They were little in that it took relatively little time to track them down and resolve them. Many applications are riddled with much deeper bugs that can't be fixed because their tentacles spread everywhere.

  • Barf4Eva (unregistered)

    "Using my scripts and cheat sheets, my peers on the other projects managed to do their ports in just a couple of hours, and mercilessly rode me about it for the next 3 years. "

    LOL... no good deed goes unpunished!!! :)

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    TRWTF is Missed 'em Five.

    I just finished reading "A Quarter Century of UNIX" by Peter H. Salus. Basically, lots of guys make a ground-breaking operating system in spite of AT&T constantly getting in the way. Once AT&T is free to commercialize it, they come up with their own release (System V), buy a good chunk of Sun, and force Sun to change from using a BSD version of Unix, with no attempt at backwards compatibility.

  • Sole Purpose of Visit (unregistered) in reply to Brian

    Interesting thing, Technical Debt. They always tell you that it will go away "when we have spare time."

    And yet it never does.

    This, btw, includes "Technical Debt" which actually causes exceptions on the client end. Exceptions can be "managed" via dashboards -- hey look, no spike! -- and don't need a code monkey to check them out. (Right up to the point where you lose a $100,000 contract, at which point it's too late, and it's the code-monkeys' fault for not knowing that.)

    We live in strange times.

  • Sole Purpose of Visit (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Er, an interesting theory.

    The only problem is (and the basic problem is that it has nothing to do with the OP) --

    That Never Happened.

    Or, at the very least, it's a dim-witted way of describing System V Release 4. Which was basically a (co-operative) attempt to solve the Unix Wars of the early 1990s.

  • Andropause (unregistered)

    This could have been a good example of the "dead cat" paradigm. There is a dead cat in the yard, someone has to remove it and nobody wants to do it. Someone finally says, "fine, I'll do it" and it turns out to be his biggest mistake. The boss has now decided that the guy will do nothing else but remove dead cats, and the interesting work is kept away from him. "Sorry son, it was your choice to remove the dead cat".

  • D-Coder (unregistered) in reply to henk

    yet another "I am great" post by snoofle; get your own blog so it's easier to ignore please

    Snoofle is God. Get your own mud puddle so it's easier to ignore please.

  • OnceUponATime (unregistered)

    I remember those days. And working with people who really didn't know how to use their source control system. I wonder if it was rcs, sccs or actually something better like clearcase?

  • TheDailyWankThesNoofle (unregistered)

    Really Snoofle?? your posts are usually above "I am Brillant and they are stupid"

    Maybe that is why they didn't listen to you?

  • Ulysses (unregistered)

    It sounds as if snoofle didn't abstract the platform incongruities, i.e. he sprinkled Jekyll and Hyde everywhere, which other teams had to repeat rather than reuse. In that case, that's TRWTF.

  • David C. (unregistered)

    The secretaries had Sun 3/60's? Why? Were they preparing documents using TeX?

    As far as I know, there was no office suite software for SunOS. The first suite for Sun hardware I know of was StarOffice 3.0 (1995, when Solaris 2.4 was the current release - about 3 years after Sun switched from SunOS to Solaris) and it would certainly not run on a 3/60.

  • Jordan B (unregistered) in reply to David C.

    Lotus 1-2-3 and WordPerfect apparently had SunOS versions, according to Wikipedia.

Leave a comment on “Walking on the Sun”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article