• P (unregistered)

    The entire WTF can be summarized as "it's kind of like your daily WTF".

  • bvs23bkv33 (unregistered)

    45 minutes to build? did they use gradle?

  • ray10k (unregistered)

    Decent story, but it lacks a proper punchline. "Boss doesn't understand technology; makes unfounded assumptions" is very much 'business as usual' for TDWTF.

  • (nodebb) in reply to bvs23bkv33

    45 minutes to build? did they use gradle?

    Sounds like they were using gradle… to build C++.

  • Little Bobby Tables (unregistered)

    This sounds very like a heavily-embellished retelling of a submission I put in a few weeks ago.

    The heart of the tale was indeed the fact that the project manager had not twigged that: a) if the vacationing colleague had not actually committed his changes to the repository then the build would not pick them up, rendering the manual build futile, and b) if he had committed them to the repository, then the automatic overnight build would have picked them up and included them in the latest build, rendering the manual build redundant.

    The message exchange in which I explained to the project manager that it was pointless to do the manual build took only about 5 minutes in total (he's savvy enough, he reacted with an "oh yes of course, well explained"), but the exchange amused me sufficiently (in the wake of a four-year-long sequence of WTFery) that I thought it worth posting up.

  • Tom (unregistered)

    The real WTF is Jackie not pushing her changes (even if they're still in progress) to a branch before leaving on vacation...

  • Steve (unregistered) in reply to ray10k

    "Boss doesn't understand technology; makes unfounded assumptions" is very much 'business as usual'.

    FTFY

  • Dave, for Oz (unregistered)

    Sometimes you just gotta tell your boss "no".

  • Brian (unregistered) in reply to bvs23bkv33

    [quote user=bvs23bkv33 ]45 minutes to build? did they use gradle?[/quote]

    I used to work at a place that had even longer builds. Not only did the build itself take a long time, but there were a whole slew of automated tests that ran as part of the build process, so a full build+test could indeed take upwards of an hour or two. Oh, and check-ins were gated, so your stuff had to successfully build and pass the tests or your changes would get rejected. And the tests were prone to random failures that had nothing to do with the code that had actually changed. Once the higher-ups found out how much consternation this was causing to the devs, they decided it would help speed things up if they bundled multiple pending check-ins together into one gated build, meaning that now your one-line bugfix could get rejected not only because of some random test failure but also because of someone else's broken code. And the bundled check-ins meant that it was never your fault when the build broke, so you just re-submit your changes... and so did everyone else, which naturally caused a vicious cycle that tended to result in simple changes possibly taking a whole day to actually go through.

    On the plus side, the frequency of build-breaking changes getting into the main repo went way down.

  • Scott (unregistered) in reply to Tom

    I imagine they're just working on the only (production) branch that exists.

    Making a branch for each development task is scary. Next, you'll want each developer to maintain local versions of the databases, to isolate changes before they're checked in.

    Sigh. Some of the stuff I am trying to get us away from.

  • Stranger Things (unregistered)

    Finally, a daily WTF story that is entertaining! And didn't rely on me having to read code, which I don't ever do. Short attention span, you know.

  • (nodebb) in reply to Stranger Things

    Short attention spa…

    Look, a squirrel!

  • ooOOooGa (unregistered) in reply to Scott

    Not sure if you are being facetious or not.

    I know there are several competing ideologies for branching for develepment, integration, and release. Having a separate branch for each development task is one of the top runners though as far as I have seen. The downside is having a billion branches hanging around.

    But I am fairly certain that having a local instance of the project database (preferably filled with dummy data) that you can test changes against is definitely a good thing.

  • (nodebb)

    Ok.

    Deploy untested changes, from a dev on vacation, code that is in an unknown state, to prod so manager can do a demo in 20 minutes?

    Yeah, what can go wrong?

  • (nodebb)

    CEO is not at fault here. One IT resource didn't commit her changes. The other IT resource configured a snail of a build. At worst you can say he should've hired a CTO, but those are usually dumb, too.

  • (nodebb)

    And the cherry on top - GitHub. Why would you use a paid centralized version control system, while there are free alternatives like Subversion?

  • Loko8765 (unregistered) in reply to Mr. TA

    You haven't worked with both, have you...

  • D-Coder (unregistered)

    "Sure! I'll just check in her unfinished changes, which might cause the demo to explode in everyone's faces, which will make those potential clients go home and tell all their contacts that our product sucks and we lose half our future clients.

    "You've got to ask yourself one question: 'Do I feel lucky?' Well do ya, punk?"

  • sizer99 (google) in reply to Mr. TA

    You pay for git so you don't have to deal with subversion any more. You answered your own question. Though you could run local git server for free too.

    And people saying it's Jackie's fault for not checking in the broken pages in progress... she probably should have made a branch before she left just so they wouldn't get lost if her laptop fell in the ocean.

    But that wouldn't help Matt in this case, because then Matt would have made a totally broken build which the boss would have shown off live and would have been worse than showing nothing - and all their other customers would have gotten the broken build too. This is completely the CEO's fault for lack of planning and communication.

  • Not SVN (unregistered) in reply to Mr. TA

    I hope you're trolling. If not, you might want to catch up a bit.....

  • Gallowglass (unregistered)

    "It was the last lo mein he enjoyed because he was fired the next day by the CEO for not meeting his needs and not being sufficiently obsequious and contrite about it. Now he's a homeless hobo and only eats scraps of unwanted moo shu pork from the chinese take out trash bins. Why does no one throw out lo mein, he cried. Why?"

  • Chris (unregistered)

    Another analogy, which you could stretch just far enough. The boss wants you to drive him to somewhere 45 minutes away, and get there in 20 minutes time. You can take the company car, which any employee can access at any time, but the boss wants to listen to the new playlist your colleague was creating before going on leave. Because the playlist wasn't left in the car, and the colleague has the playlist with her, you can't use it without reproducing it yourself.

    You can always use a car metaphor.

  • (nodebb)

    If he does indeed understand Star Trek references, why not use "You cannot change the laws of physics, Jim!" ?

  • doubting_poster (unregistered) in reply to ooOOooGa

    Billions of branches lying around is a sign of a bad work process or undisciplined workers, not a problem with 'one branch per task'. Once the task gets merged into main/master/production/whatever, the branch should be deleted. That way the only branches that exist are work in progress, which is an immediate insight into which tasks may be hanging around too long.

  • ZZartin (unregistered) in reply to Tom

    That would have been a completely different TDWTF if the changes she pushed before going off the grid didn't work....

  • DanK (unregistered) in reply to doubting_poster

    If you delete your branches, how do you maintain traceability?

    With Subversion, you can at least go back in history and recover your branches, but AFAIK, when a git branch is deleted, it is gone forever.

  • (nodebb) in reply to dkf
    Short attention spa…
    Look, a squirrel!
    Short attention squirrel
  • Worf (unregistered)

    Methodologies in code control vary, and usually depend on what is supported. Branches are popular because in git, they are effectively free (creating a branch just creates a new pointer to the current HEAD). Some, like in Perforce, can take forever (always great fun branching the kernel project, it will stall out for 20 minutes and you better not touch anything because the X server can get unstable), so you generally don't branch and just work on changesets at a time.

    Plus, the merging tools vary in quality, which reflects on how you merge branches back into mainline.

  • NULLPTR (unregistered) in reply to DanK

    If you ensure a merge commit is always created on merging a branch you still know where they were. Then you just need to checkout that commit and give it a new branch label

  • ooOOooGa (unregistered) in reply to doubting_poster

    If the major downside to one branch per task methodology is 'I have to remember to delete branches after the task is done', that doesn't sound very scary to me.

    And (at least in git) deleting a branch doesn't delete the commits the branch was made from. Those are still there for traceability.

  • jgh (unregistered)

    Can't you just hack into it? Not unless it's plugged in and switched on. Can't you hack into it and switch it on? Not unless it's plugged in. Can't you hack into it and plug it in? Not without a very fast car and a sledgehammer or that fictional teleporter we mentioned earlier.

  • Rocky (unregistered) in reply to ray10k

    It's pretty much business as usual for the majority of companies.

Leave a comment on “Teleported Release”

Log In or post as a guest

Replying to comment #:

« Return to Article