• Well well (unregistered)

    The real WTF for me is how come project configuration was letting developers pushing directly to the main.

  • (nodebb)

    One word: YIKES.

    That sums it up. I'm going to be fair I've seen very few teams actually do automated testing let alone really push it although 100% code coverage is a pipe dream having something to prove that your code works is always a good idea

  • (nodebb)

    Well at least she wasn't unaware of her pregnancy for 9 months: https://www.msn.com/en-us/news/us/butler-county-woman-didnt-know-she-was-pregnant-delivers-christmas-miracle/ar-BB1c36B4

  • Sole Purpose Of Visit (unregistered)

    Quis custodiet ipsos custodies?

    Gotta feel sorry for the newbie. Now that I come to think of it, I've never seen a project lead have their responsibilities stripped from them on the grounds of dangerous incompetence. You can have all the process and bells and whistles in the world, but if your lion cubs are being led by donkeys, you end up in a mud-soaked trench being shelled by poison gas canisters.

    (Enough metaphors for you?)

  • Prime Mover (unregistered)

    If Felicia worked for me, then prospects for her continued employment would be on very shaky ground indeed.

  • DanJ (unregistered)

    The real WTF: Why in the hell does a junior developer have access to modify the YAML file controlling the test runner?

  • (nodebb)

    Roger, understandable (forgivable)..... Felicia? What ever happened to the days where there was (allegedly, I admit nothing) a black list burried deep in the industry.

  • RLB (unregistered) in reply to Prime Mover

    If Felicia worked for me, then prospects for her continued employment would be on very shaky ground indeed.

    Yup. TRWTF here is not Roger, but Felicia.

  • doubtingposter (unregistered)

    At my current enterprise job, it's a sort of badge of honor for every new developer when they break the master branch in some serious way. From leaving debug flags on, breaking the deployment scripts so no new versions can be built, to force pushing with the prune flag on (deleting EVERY branch that this developer didn't happen to have checked out). It's a learning moment, we acknowledge that people are human and in a good development environment It should be easy enough to fix (though the prune was quite the pickle!)

    But any senior or supervisor that would let such a mistake slip and conciously STAY on the master branch.... yeah that would be a fireable offence.

  • Pabs (unregistered)

    The question is did the resulting problems take another 10 months to fix?

  • 516052 (unregistered)

    This is not a WTF. It's tuesday.

  • Chronomium (unregistered)

    Honestly, if you go an entire month without any CI failures, you should be suspicious.

  • David (unregistered)

    #ByeFelicia

  • Hal (unregistered) in reply to doubtingposter

    I have a feeling we are not getting the entire tale here. Its hard to believe Felicia really allowed this all because to do so would be to completely undermine all the value of automated ci/cd, tdd, and even version control itself. How someone could lead anything and not see that is beyond my imagination.

    More likely if you ask me is Felicia made some exceptions for Roger one time that were supposed to be temporary. Roger is was either actually green enough to misunderstand this was not to be SOP or more likely Roger the calculating sort that said 'hey this is easier for me at least until I get caught. When I get caught, I can play dumb an blame Felicia'.

    And let that be a lesson to anyone you in any kind of leadership role. Granting policy exceptions to those who report to you might be with in your power, it might even be your job to exercise that kind of judgement, but make sure you set the bar really high. You are going to be the 'owner' if anything goes wrong, in general which you knew but more than that you can count on your willingness to be flexible to be taken advantage of.

  • (nodebb) in reply to Chronomium

    Honestly, if you go an entire month without any CI failures, you should be suspicious.

    We get CI failures all the time. However, they are usually addressed within minutes or hours.

  • null pointer (unregistered)

    Tests were failing for 10 months and nobody noticed that the product had bugs? It must have been not used by anyone, or they have lots of dead code.

  • Sole Purpose Of Visit (unregistered) in reply to null pointer

    That's not really the way these things work.

    (A) Collect Product Features (B) ? (C) Profit!

    The problem here is that (B) depends upon (A). You can sign up as many customers as you like on (A), but they're going to keep being customers if you get (B) right.

    It helps if you can test the underpants. Otherwise you never get to (C).

  • Sole Purpose Of Visit (unregistered) in reply to Sole Purpose Of Visit

    not going to keep being customers. Darn.

    Point is, customers who see your product as "deformed and useless", for some variety of "deformed and useless", are not going to stick by you.

    There's undoubtedly a point before which your customers completely abandon your product. Customers are long-suffering, once they've been introduced to your Product Cult.

    Then again, if you really want to lose them by being hopelessly incompetent and by breaking things ... Hey. It's a lifestyle choice. Not financially the one I would choose, but money and professionalism and quality and delivering some form of what the customer expects doesn't matter to everybody, I guess.

  • Sole Purpose Of Visit (unregistered) in reply to Jaime

    Um ... I don't think you've quite got the point of defining "fail" as "pass."

  • (nodebb) in reply to null pointer

    Or more likely, requirements changed and the tests that were failing are obsolete.

  • (author) in reply to Sole Purpose Of Visit

    It could be an Enterprise product, in which case "deformed and useless" is pretty par for the course, because there's basically only room for one vendor in the space, especially after you buy out your competition. /cough/ oracle /cough/

    Addendum 2021-01-21 13:01: Not saying that this article is about Oracle, I literally have no idea who the article is about. I'm just saying Oracle's entire business is selling garbage at extreme price points.

  • If it works, it ain't stupid (unregistered)

    Yeah, if nobody noticed this issue for 10 months, the whole team failed hard. The junior dev as an individual is virtually faultless in my opinion. They did what their lead told them, and they met their deadlines. The team as a whole failed really hard though. If the team had the type of culture that allows this to go unnoticed for 10 months, there's nothing a junior dev can do to fix it.

  • (nodebb) in reply to Remy Porter

    Pooping on oracle is literally music to my ears. The successful existence of their business model is TRWTF.

  • (nodebb) in reply to DocMonster

    In my project, test coverage is counted in "code that doesn't crash". There are no formal tests that check the results, when the program does NOT crash.

    Addendum 2021-01-21 14:19: No automated ones anyway.

  • Is That Really A Crosswalk? (unregistered)

    So there's a lead, juniors, and whatever level Rubi is at? Sounds like there's too many programmers and Rubi will be asked to leave.

  • xtal256 (unregistered)

    I've lost count of how many times I've been in that situation. Trying to convince people to do the right thing instead of the lazy thing is like pulling teeth.

  • 516052 (unregistered)

    That's why I prefer mercurial to git. It's just easeier to use and overall better. Although I do miss the good old days of floppies. I still keep some around in my room as a lucky charm.

  • MiserableOldGit (unregistered) in reply to Remy Porter
    Not saying that this article is about Oracle, I literally have no idea who the article is about. I'm just saying Oracle's entire business is selling garbage at extreme price points.

    Ten months of absolutely nothing happening but meetings and finger pointing on that suite of products is so normal it doesn't even get remarked upon. I once spent three years providing sunset support to a load of spreadsheets/databases that were being "replaced" by OPA. At the end of it I was being offered a job on the OPA team as I had spent my time fixing and deploying stuff they kept saying was impossible to do ... I'd actually fixed nearly all the problems that had led to the original business case for the replacement in less time than it had taken them to (fail to) configure their hilariously expensive product ... and this was me with 1.5 other guys, compared to a team of 30.

    I didn't take the job, I'd rather lick warm shit off a cactus than work with OPA.

  • (nodebb) in reply to 516052

    Although I do miss the good old days of floppies. I still keep some around in my room as a lucky charm.

    In my case it's basic laziness about digging them out and putting them in a rubbish bin, but yeah. Of course, it's been ten years since I had a machine that had a motherboard connector for a floppy drive, and 1.44 KKiB(1) really isn't enough to be useful any more.

    (1) It's 2880 sectors of 512 bytes each, which is equal to 1440 binary K, i.e. 1440 K(decimal) of K(binary) = 1.44 kilokibibytes.

  • Prime Mover (unregistered) in reply to R3D3

    Heh. Automated systems.

    We have an automated email system which alerts a team when someone raises an issue on the IT service app. It is the task of whoever is on the rota to monitor the emails and assign the issue to whoever is best placed to address the issue.

    So it rolls round to me one week, and it's half way through Monday and there's nothing come through. I raise the question with my colleagues:

    "Had nothing through from the queue yet today, and nothing from over the weekend. Come to think of it, nothing since midday Friday. Can we check the job is running? Does anyone know how to do that?"

    This was the gist of the subsequent conversation:

    Colleague: "The service requests come in via email, which you're supposed to be monitoring. I thought you knew that."

    Me: "Yes I know that. That's not what I'm asking. I wanted to know whether there's a problem with the queue."

    Colleague: "All you need to do to service an incident is to click on it and it takes you to the entry in the IT service logging system. Then you will be able to see who's best to answer it. It's not rocket science."

    Me: "That's not what I was asking. I was asking how we can check whether the queue is running. Who's responsible for it?"

    Colleague: "Come on, wake up at the back. It's your responsibility this week. Whenever there's an entry in the queue, it sends you an email, and you have to enter the ticket by clicking on the link (you were taught this on your training course) and see what it's about, then assign it to whoever is responsible for that area of the application. If this is too difficult for you to grasp, perhaps we ought to go to our manager and see whether you're fit for this position after all."

    Rinse and repeat.

  • 516052 (unregistered) in reply to Prime Mover

    Serves you right to be honest. If it's your day for the queue and nothing comes than nothing comes. No need to rise a stink about it. If the system is broken it will be eventually detected by someone down the line. Someone who will than have to fix it or worse yet get responsibility for making sure it keeps working.

    Someone that isn't you.

    Seriously, that is why you get the responses you do. Nobody wants to be that someone. And to them it sounds like you are trying to recruit them.

  • 516052 (unregistered) in reply to Steve_The_Cynic

    Yea, those were the good old days. Back than kids understood the value of a byte. Not like today with their DVDs and USBs and terabyte hard drives. Nobody cares about optimization any more. They just bloat bloat bloat and fix every bug by adding more bloated patches on top. Check for cause? Who needs that? Just patch the end result.

    void longFunctionWithError() { stuff that makes error

    //Patch
// return result
if(that special case QA noticed) return fixed value instead

    }

    That's why back than all software was good and bug free and fit on a floppy and now all we get are bloated mess products the size of a whale that do the job of a fly and do it badly.

  • Prime Mover (unregistered) in reply to 516052

    Were you born that way, or did you have to work at it? I have never encountered such a more useless waste of resources than you.

  • (nodebb) in reply to Prime Mover

    @Prime mover, that sucks beans. So frustrating.

  • MiserableOldGit (unregistered) in reply to Prime Mover

    Sounds rather like a colleague I once had ... a very siloed organisation where I could get no information or anything without getting him to do it for me.

    He handed me one of his always useless requirements documents one morning. I said three things on it, one useless and irrelevant and the other two flatly contradictory. I kept pointing this out and saying i couldn't work with the document unless he got this clarified (maybe both were true and there was another important piece of information I needed).

    All I got was louder and louder shouty nonsense about it being my job to work with the requirements and produce a result.

    And then later one he tried to have another shouty session about how I'd made him look stupid in front of our boss ... "Urrm, it wasn't me did that!"

    I'm not sure anything I wrote there ever worked, and I never felt responsible for it one tiny bit.

  • (nodebb) in reply to 516052

    If the system is broken it will be eventually detected by someone down the line.

    It was detected, by Prime Mover, and the team beat him down for it. I've been there before. This will go completely unaddressed until someone important has an issue and discovers that it didn't get to the help desk. Then, instead of fixing the current problem, they'll go buy some expensive monitoring product and configure it to be almost as useless as the previous solution.

    What they really need is Google's post-mortem rule: if an issue wasn't detected by the monitoring system, fixing monitoring is a priority one to-do.

  • (nodebb) in reply to If it works, it ain't stupid

    The junior dev as an individual is virtually faultless in my opinion.

    It's now 10 months since he did it and, if the conversation as reported is correct, he still doesn't know that what he did was a WTF. There's more serious failings in that org than just the one 10 months ago.

  • Simon (unregistered)

    Am I the frist person to notice that in the second paragraph Rubi is "Ruby"?

  • idontknowwhatamidoing (unregistered) in reply to null pointer

    or meaningless tests. existing for the sake of existence

  • (nodebb)

    Recently, Ruby pushed a commit on a branch up,...

    Who's Ruby?

  • Simon (unregistered) in reply to PJH

    I beat you to it, on the 37th comment, withheld for moderation. So, only 33 people who commented can't do syntax, and I think you'd agree that means we should discount any of their opinions about ANYTHING.

  • Simon (unregistered) in reply to 516052

    I started doing software from a background of electronics engineering. Indeed, I haven't any letters after my name except those of being MIEng MIET, the Btritish Computer Society turned me down for being too young so I didn't bother with them any more considering they don't understand the words "meritocracsy" or "hypocrisy".

    I can imagine who in the commenters here are old hands who actually have seen things happen very badly wen software goes wrong. I work on safety-critical software. amd I have rather different considerations from what DROP TABLE does. If my software goes wrong, I could kill someone, and I will be held personally liable. THAT is when you start writing software carefully.

  • 516052 (unregistered) in reply to Prime Mover

    I troll therefore I am.

  • 516052 (unregistered) in reply to Jaime

    And when that happens it won't be his fault AND he won't be the one stuck maintaining it. Where as if he keeps bugging everyone about it they will still do the same thing but he'll be the one stuck with it. Or worse he'll be punished for being disruptive and annoying people with complaints. Seriously, keep your head down and do your job. Let tech support worry about problems.

  • MiserableOldGit (unregistered) in reply to 516052

    May not be his fault, but I bet he'd still get blamed. That's certainly the way it works in most places.

  • 516052 (unregistered)

    Only if he is the last guy that has to interact with the system before the inevitable meltdown. And given that they seem to be trading that responsiblity off so that each guy gets one day his odds are 1/7. Which isn't terribad.

  • MiserableOldGit (unregistered) in reply to 516052

    It's fair point, but he made the mistake of not keeping his mouth shut.

  • 516052 (unregistered) in reply to MiserableOldGit

    Fair point. Hopefully this will be a learning experiance about sticking your head out.

Leave a comment on “Failing the Test”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article