• Brillant (unregistered)

    Frist

  • (nodebb)

    Been there, done that, burned the t-shirt on the desk of the admin and laughed as each deployment after that failed in the same fashion.

  • LH (unregistered)

    Ah, Rational ClearCase and Holy Change Management. I so do not miss you.

  • TheCPUWizard (unregistered)

    Alas, far to common of a fundamental problem..... <sad face>

  • JRandomPMP (unregistered)

    I wish I could say that this is an exception, but I've seen far too many examples of this.

    It makes me ashamed of my profession.

  • Np (unregistered)

    Similar crap at my company. Spreadsheets to manage changes they clobbered and forcing developers to reinstate them. Wish they could just do branching like it is supposed to.

  • PeterK (unregistered)

    Crap like this makes me terrified of my own career. Thanks DailyWTF. :p

  • keepanon (unregistered)

    "Change and Release Approach Policy", ha ha I get the acronym.

    "Changes Under Merge", ummm is that a sexual reference acronym?

  • Joseph Osako (google)

    Wait, where did things get overwritten? It couldn't have been in the development copy he was working on, since no one else would have had access to it until he packaged it into the changeset. It shouldn't be possible to silently overwrite anything in Truly Fucked-up Shit (or any other VCS I have ever heard of, except maybe TFS's predecessor, ViolentShitStorm), so he would have seen the changes made in the change log before he even got to the code itself, at least I would think he would. So... the changeset got overwritten as it was being submitted? That's an epic fail for the change system, no question, but again, how is that possible? Isn't preventing that sort of thing part of the purpose of a change mangling system?

  • jmm (unregistered)

    all of this over-management for a measly "1.2 million lines of code" ???

  • David (unregistered)

    Banks can manage to let developers merge branches on mission-critical systems, so it's not universal. Better off out of that kind of company, where the blame falls in the wrong place while the culprits manage to expand their ranks. Some project managers are really useful - managing expectations, keeping everyone informed, etc. Unfortunately, in a traditional case of 'shoot the messenger', these bearers of bad news who actually try to facilitate communication get blamed for the timescale 'slips' that were a simple case of insufficient resources for a fixed deadline and end up mired in baseless misconduct meetings. They won't stoop low enough to just pass the blame on to random developers, so they get the occasional black mark hampering their careers while the truly self-important and incompetent ones will do anything to save their own asses, pass on the blame and climb the greasy pole. After climbing over the mistreated bodies of former co-workers, they want to continue add additional levels to blame between the developers and themselves (and expand the team under them) so they press for more junior managers, thus increasing the over-management problem.

  • JustSomeDudette (unregistered)

    Best easy reader version ever.

  • operagost (unregistered)

    All that bureaucracy to allegedly prevent code from being broken, and not only does its byzantine nature result in a break in the code (caused by another coder who somehow escaped blame) but they have so much confidence in the process that they don't bother having a backout plan.

  • Nicholas "LB" Braden (github)

    I on;y have experience with git merging - is merging more difficult or annoying on other VCSs? What would prompt management to do this kind of nonsense?

  • Remy Porter (google)

    The specific issue here is the TFS "baseless merge", which basically ignores branches entirely. It's a really good way to screw up your history if you're not careful. It's basically included in TFS as a "bad stuff can happen, and sometimes you'll need this to force a sync across branches that don't connect, but don't make this part of your workflow, or else bad things will happen."

  • lordofduct (unregistered)

    I don't think I've ever worked anywhere where anyone knew how to use branches... ever.

    It boggles my mind.

  • David Green (unregistered)

    My previous employer did something similar. We weren't allowed to commit to our QA or Trunk branches, so we did a "mock merge" in which we merged, documented our merge conflicts and how to handle them, undid our merge and included it in our change request. Then the person doing the deploys followed the merge steps, generally messing it up. Lather, rinse, repeat for Trunk for a production deploy.

  • (nodebb)

    Sounds like the best possible outcome for David!

  • TheCPUWizard (unregistered) in reply to Joseph Osako

    Joseph... regardless of the system if one does:

    1. Get files from a given source (branch A, changeset X)
    2. Manually edit files.
    3. Put file into a different target (branch B, changeset Y)

    Then

    a) There is no record of the source changeset in the target. b) One can not compare files as there may have been dozens of different edits

  • Herby (unregistered)

    All of this makes you wonder what people did before SCCS (and before "project managers").

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to LH

    I used to work at Big Teal, and even with some of the hairy cherry-pick pulls we regularly did in QueerCase, it had nothing to compare with this level of WTF.

  • (nodebb)

    “We don’t think this organization is the right fit for you.”

    What I would have said as three people trudged by to tell me I was doing it wrong and set up meetings describing the Right Way to get changes into the tree.

    Of course, not having such an overview during orientation (which would also have ticked off my WTF senses) is also a WTF, but here you go...

  • Nicholas "LB" Braden (github) in reply to Remy Porter

    @Remy yeah but I was wondering why they so badly wanted to avoid merging?

  • snoofle (unregistered) in reply to Nicholas "LB" Braden

    Merging is hard and unreliable; manual processes are easier and more reliable - always; without exception; at any cost - because managers know best

  • CrushU (unregistered)

    I figured out my interviewing strategy. I'll claim that we don't do any automated testing. If the candidate doesn't ask why, or accepts it, NO HIRED. If they ask why, or state that doesn't make sense, they can proceed. If they ask if they can implement automated testing for their own code, HIRED ON THE SPOT.

  • (nodebb) in reply to PeterK

    I see what you did there.

  • jo (unregistered)

    How should one pick up on this sort of WTF during an interview? Is it acceptable to ask for details of a companies build procedure, VCS and Automating testing policy? Luckily I've avoided this type of WTF thus far in my career, and would like to keep that streak.

  • Tim (unregistered)

    The number of managers stopping by was right out of Office Space.

  • löchlein deluxe (unregistered) in reply to I dunno LOL ¯\(°_o)/¯

    Did we want to know about your hairy cherries?

  • boanergesza1 (unregistered)

    "Yeah, im going to need you to put the new cover on your TPS merge reports.MMMKay"

  • foxyshadis (unregistered)

    It's amazing how far some companies will go to disconnect developers from their code, and tell them how little they're trusted. Because what you really want are people who have no investment and no incentive to do more than show up every day.

  • Jistax (unregistered)

    It scares me that there still are companies working this way :o

  • (nodebb) in reply to Remy Porter

    The specific issue here is the TFS "baseless merge", which basically ignores branches entirely.

    Sounds like it is combined with a policy of sometimes just copying files over entirely instead of integrating changes from both sources. I've worked with people who did that (and who thought that SVN could only ever commit stuff with the force option, so always used it). It was hugely frustrating to have half your changes squelched because someone just didn't do updates to bring changes by others into their workspace. Combined with a cherry-pick all the things approach to merging, I can see why this would be a catastrophe…

  • D-Coder (unregistered) in reply to jo

    It's definitely okay to ask about their procedures. I always ask what they use for source control and how often they do backups. (I'll accept almost anything other than "nothing / never", but those responses would be Big Red Flags.) I also ask to see some of their source code to make sure the variables aren't named "A1", "A2", "A3" etc. They may refuse, or they may want to see something of mine in return; I have a nice code sample ready.

    I learned these from years of reading TheDailyWTF as well as personal experience.

  • Wayne (unregistered)

    I would not have stayed on for 6 months.

  • Paul Neumann (unregistered)

    All I learned about was Remy's coprophilia.

  • Dathan (unregistered) in reply to CrushU

    Heh, that'd be nice. I interviewed someplace once where I got into a fight with the team lead about automated testing. I gave up after he said "We're never going to follow test-driven development. Having to introduce an 'IMessageBox' interface so we can pass a fake message box to test that we pop up a message box is stupid when we can just run the code and see the message box."

    I did not get hired.

  • (nodebb) in reply to Dathan
    I did not get hired.

    More accurately, you righteously filtered them from your employment future.

  • GorGutz 'Ead 'Unta (unregistered)

    What's with companies for some reason being afraid to let their employees touch the things they're suppose to be producing? What are they afraid of?

  • LH (unregistered) in reply to Joseph Osako

    In my former job, people would just get a branch, overwrite anything in it with their "development version" (usually, based on a completely different and most of the time outdated branch) and then push the changes to the development branch. Repeat for 10-20 developers working on parallel projects or more for any given "Release", and if you were done early you'll get your changes completely obliterated, because ClearCase was just really dumb catching conflicts.

    Management acted not very different than the one depicted here. So, if you wanted to survive, you either learn to be an asshole and do the same (overwrite previous changes,) or care and be deemed a troublemaker and get lousy performance reviews (after all, you were the one delaying the release.)

  • LH (unregistered) in reply to GorGutz 'Ead 'Unta

    What's with companies for some reason being afraid to let their employees touch the things they're suppose to be producing? What are they afraid of?

    In my experience, it's always consequences of some ill-advised performance improvement plan tied with productivity bonuses. Upper-tier management need to justify their decisions on metrics, and these always get played so they look good on paper, technical debt be damned.

  • Gummy Gus (unregistered)

    At my last place they had one Wizard who was handed two source trees that had diverged over 2 years into a "USA" and a "Asian" branch. The Asian branch had been tweaked-over by about a dozen developers, for two years. No merging had been done. He spent about 6 months in "meld" staring at wildly divergent sources and merging. A far, far better person than me! I would've run off screaming if given that task.

  • Syntaxerror (unregistered) in reply to Joseph Osako

    It got overwritten because the CUM-Team did a baseless merge first with the Davids code and then with Liams code, which has overwritten Davids fixes. It's beyond me, why Liam doesn't get any shit from the managers. It's understandable, that David couldn't see that his 6 months worth of code have been changed in a (probably) very minor way in a timeframe of 2 hours. Who would, really?

    The only way to get SOME sort of confidence in the 2 hour window would be, to convert the Spreadsheet to text and run a File-Compare with all of your own code over it.

  • Guest (unregistered)

    I can see how this started. Management bought in consultants to improve productivity, then the consultants surveyed everyone on how the spend most of their day.

    A constant among the developers was that the spent a lot of time merging and deploying tests when they "should" be programming 8 hours a day.

    So the solution was to get rid of these pesky menial tasks and have them done by low paid workers who don't know what source code is.

    Instant productivity improvement right?

  • Guest (unregistered)

    I love it, how they fired you and not the whole management team, which is clear was crap.

  • Peter (unregistered) in reply to Herby

    In those days, the last person to press "save" was the winner. The last company I worked for that lacked source control was in 2005.

  • MT (unregistered)

    "We need to expand the management team so that we can avoid these problems in the future. And since our headcount just shrank…”

    The bureaucracy is expanding to meet the needs of the expanding bureaucracy.

  • eric bloedow (unregistered)

    reminds me of that silly "allegory" story about how the Japanese rowboat-racing team beat the American team easily, because the american team had ONE rower and 10 people yelling "stroke!"...THEN tried to improve it by having 12 yellers and still only 1 rower...

Leave a comment on “Twisted Branches”

Log In or post as a guest

Replying to comment #:

« Return to Article