• (nodebb)

    "he beheld a dozen people or more crammed all along the perimeter of his cube and spilling into its cramped confines. Some were in fancy business suits, some in full military regalia. All were wearing the most furious expressions he'd ever seen." -- been there, seen that..... definately not fun.

    Having proper documentation is a key element, and unfortunately all to ignored in most circumstances today.... Here is a simple test. Find a pice of code written over a year ago.... Not go find out why that code was written that way [bonus points if the person or team responsible is no longer with the company]....

  • Robin (unregistered)

    I'm left with more questions than answers. What was the actual problem? Why weren't the planes able to fly? What did the polynomial function have to do with it?

    And more importantly, what testing or code review, etc, was done on this apparently critical function. While happily it seems Argle wasn't to blame here, if something that critical is failing due to faulty code from a 17 year old kid, it's the process that's a WTF, not (just) any particular piece of code.

    And if they really chuck code into production without so much as a glance at it, where "production" means controlling actual planes that travel very fast into and through the sky (and possibly have weapons, given the reference to military people), I feel bad for anyone who had to actually fly in those planes!

  • (nodebb) in reply to Robin

    I suspect this was before the concept of code review was a thing, or was too new for everyone to know how important it was to use. The reference of Fortran is a good hint to that.

  • Brian Boorman (unregistered) in reply to Robin

    I don't think it was faulty code so much as more likely that the person who (obviously) hand computed the curve-fit coefficients made a mistake in his math.

  • Brian (unregistered) in reply to Robin

    Yep, I've worked in such an environment before (note the past tense). Maybe things have changed by now, but the projects I worked on and the people I worked for were always hardware-focused. Software was just a necessary evil to make their expensive doodads actually do something, and software design was treated much the same way as hardware design: lay out all the specs and requirements up front, prove that it all works flawlessly on paper before even a prototype is built, then you can get your pool of cheap, low-skilled labor (or alternatively, highly-paid contractors) to simply assemble it.

    So of course when something goes wrong, obviously it's not the high-ranking managers and systems engineers who made a mistake, it's the poor schmuck at the bottom of the totem pole who's to blame for everything. And people wonder why there's so much waste in military spending...

  • (nodebb)

    Damn it, it was done in Fortran, so we cannot blame PHP for it.

  • (nodebb)

    Unfortunately I misread the name so I spent the whole story wondering if, after getting fired because of the WTF, he got a job as a limousine driver and got fired from that job after deliberately t-boning a truck in the carpark of a new office block in LA.

  • my name is missing (unregistered)

    In my first job I wrote part of the Jovial (Language) math library (not provided by the vendor) that implemented transcendentals for Mil-Std 1750A and Z8000 processors, which were going to be used on the upcoming F-16's updated computers. Yes, the jet. I tested everything thoroughly and it worked according to requirements, but I thought it was pretty slow since my understanding of the math was sort of iffy (I used Taylor series). My biggest fear was always hearing of an F-16 in a dual being shot down because the missile they fired sat there for 20 seconds before leaving the rails, all because my code was too slow. I left before it was ever used, so no clue if it actually was used or not.

  • (nodebb) in reply to Brian

    Problem is, when you do it that way, there's no requirements validation until the thing is actually built. So much waste is implementing bad requirements and it getting all the way to the end product.

  • ipguru (unregistered)

    The only WTF I see here ie that they acualy still had the necessary paperwork to show they had delivered what was asked, normaly that is long gon & the guilty party denighs all knowledge of ever having even been in the same room as you before

  • Morningfrost (unregistered) in reply to Mr. TA

    Well, if you really want to: https://stackoverflow.com/questions/50544105/execute-fortran-program-from-php

  • Argle (unregistered)

    Since I was there, I can comment on the story.

    1. The office space was formerly an open area with those old Steelcase desks. At the time of the story it had been converted to Herman Miller cubicles (courtesy the same company located a mile to the west of us). Aisle space was about 2 feet. To say that the situation was stifling would be an understatement.
    2. I headed to college full-time a few years later. In a systems analysis class (required for anyone tech so it was a big class) the professor wrote in giant letters CYA and announced that it stood for "Cover Your Posterior." The class was full of very bewildered students. At 20, I was already jaded and knew what it stood for the moment he started writing and knew exactly where this lecture was headed.
    3. Mr_TA, I want to sob on your shoulder. There's just so much to blame PHP for. I have a story written for the DWTF that I don't recall if I sent it in or if it was put up, but it had to do with a C# project that was complete that was scrapped for a PHP re-write. The story causes wailing and gnashing of teeth.
    4. Robin, I don't know that the planes didn't fly. But I'm pretty sure that in actual flight tests they only provided feedback at first. That's where the problem showed up. As for code reviews, we did them. But no amount of reading coefficients of polynomials is going to tell you if they are right or wrong.
    5. ipguru, maybe I just got lucky. I had a nearly empty drawer with hanging folders and the couple pages of docs seemed important so I stuck them in there. I'm glad I did.
    6. Jeremy, the limo driver was my dad (after he retired). There needs to be a WTF site for his profession ... and his ended after a shootout involving a mob boss.
    7. TheCPUWIzard, a couple years after the story took place, I was on a tour of a big firm (AC Delco as I recall) that was showing off their state-of-the-art computer controlled inventory system that had been designed only 2 years before and was up and running. Number of original developers still on the project: zero.
  • Hasseman (unregistered)

    yep, all these TLA's make new projects interesting. You should know how many not asking what TLA means ...

  • Criticas (unregistered) in reply to TheCPUWizard

    I saw a blog post on commenting your Git commits. The best advice was "Write WHY you did something, not WHAT you did. The commit shows what you did. Only you know why, and you'll forget by the next time you look at the log."

  • RussellWakely (google) in reply to Criticas

    I'd settle for any information whatsoever about the commit: I freeze in terror when i see commit messages like "just a change" / "a few small changes" (quoting verbatim here) from a company that contracts to us, as it invariably means 10 unrelated breaking changes bundled into one

  • markm (unregistered)

    The main way to test a function that calculates a polynomial is to plug it into a graphing program and plot the curve. A big mistake ought to be obvious to someone who understands how the function will be used. A little mistake that doesn't change the shape of the curve but only moves parts of it up or down a little might pass this eyeball check, but it won't "keep the plane from flying."

    A small mistake might make the plane slower or less efficient. I would recommend a second check for accuracy, hand-calculating the value at several points between the ones that were specified and used to calculate the coefficients and comparing to the function output. If you only check the points that were specified, a poor job of curve-fitting will give a curve that hits those points but is all over the place in between them.

  • clubs21ids (unregistered)
    Comment held for moderation.
  • clubs21ids (unregistered)
    Comment held for moderation.
  • Craig (unregistered) in reply to Criticas

    "Why" not "What" makes more sense for comments. For SCM commits, having a brief synopsis of "what" is also useful, because sometimes you'll be reviewing the history of a file (or folder) looking for a particular "what". Or sometimes, you're not quite sure what you're looking for, but you have a sort of a general idea, and having a bunch of "what"s will help narrow it down.

  • Confused (unregistered) in reply to Jeremy Pereira

    I'm sorry, what is the limousine driver comment about? I do not get the reference.

  • james davis (unregistered)

    Crypto Recovery Services Crypto Recovery Services, Houston, TX. 1 talking about this. How to recover lost, stolen, hacked, forgotten and scammed crypto currencies from fraudulent investment platforms Website: www.cryptoreclaimfraud.com

  • james davis (unregistered)

    Crypto Recovery Services Crypto Recovery Services, Houston, TX. 1 talking about this. How to recover lost, stolen, hacked, forgotten and scammed crypto currencies from fraudulent investment platforms Website: www.cryptoreclaimfraud.com

  • David Añez (github) in reply to Confused
    Comment held for moderation.

Leave a comment on “Court-Martial”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article