• MrH (unregistered)

    First?

  • Yog-Sothoth (unregistered)

    You misspelled frist, and I'm going to get you last Wednesday for that.

  • DocMonster (unregistered)

    Uhh no. Sounds like someone who had the right idea (i.e. branching) and then forgot to read after that. Branches are for features/experimental things and get merged back into Trunk (or master, or whatever your VCS calls it) when done, and then optionally the next set of features gets branched off of that as well. Branches don't stay around forever (tags might, however).

  • Matt Westwood (unregistered)

    Dammit you, I was looking forward to rearing up over the Douglas Adams comment (or perhaps coming up with an even wittier quip), but then you went and apologised! That's as antisocial as a porcupine in a condom shop!

  • Matt Westwood (unregistered)

    ... and I was hearing Gordon's words in Sheldon Cooper's voice, is that so very bad of me?

  • Mike Dimmick (unregistered)

    It felt slightly like a nightmare of continuously maintaining old versions of the software, which is a WTF in itself. Customers shouldn't stick on an old version of your software forever - fixes for anything non-critical and new features should be going only into your main development branch. If this is happening, it's usually due to a lack of confidence in the new version, or your backward compatibility is horrible, requiring huge costs to migrate any code interfacing to the product to the new version. It can be unavoidable if you made fundamental mistakes in your original design that can't be corrected, or if you haven't abstracted away the interfaces from underlying data structures - you either get locked into a bad structure or you break the customer implementation when you change the structure. Neither is particularly appealing.

    I have suffered what I call the 'banana tree' approach (it 'walks' over time) in the past. The usual issue is that some major refactoring occurs on a branch, with so much code churn that it becomes unmergeable (no developer can understand all the conflicts that occur). New development then goes forward on the new branch. Our old client app (.NET Compact Framework, dying a death) suffered this as it has no automated tests and minimal human testing resources, giving the lack of confidence I mentioned above. The solution to it is not to do major refactorings in one go - do small refactorings piece-by-piece and merge back to your unstable development branch regularly, so the conflicts are manageable.

  • Pietro Gagliardi (andlabs) (unregistered)

    This and similar stories are making me start to worry that we're moving from no source control to misusing source control as a general trend...

  • Nullivator (unregistered) in reply to Mike Dimmick

    If this is happening, it's usually due to a lack of confidence in the new version, or your backward compatibility is horrible, requiring huge costs to migrate any code interfacing to the product to the new version.

    ...or you're charging an arm and a leg for upgrades.

  • Jared (unregistered)

    I'm rather curious at the number of stories about recent grads who come out of university and seem to do better then long time developers. Its not that I mistrust it (as it has even happened to me personally), but usually when I see new grads their dev skills are... lacking. For instance, most Jr. Devs I have worked with generally "know" about source control but not much more.

  • Codethulhu (unregistered)

    I endorse Gordon's plans to branch things and never actually deploy any features or fixes.

  • Literary Critic (unregistered)

    If you need to slam overly complicated and detailed writing I suggest the works of Dan Brown.

  • V (unregistered) in reply to Jared

    Most of those stories are like this one though...little to do with actual development and more about asinine policies and procedures. Anyone can identify that WTFery... Despite having little to no relevant skills, if I joined a house building company and they were putting down carpet before the roof was up, I'd notice that's not right.

  • just me (unregistered) in reply to V

    Which raises the interesting question: if those problems are so obvious, even to someone completely unfamiliar with the domain, why don't the people involved see them?

  • DocMonster (unregistered) in reply to Jared

    I would agree, but I also think in a lot of cases you have "senior" devs that have just stagnated. Like they get by doing the bare minimum without rocking the boat, so they refuse to learn or improve for fear of starting to rock the boat. Which then has the drawback of them being stubborn old codgers, as it were, when a junior or even someone just new to that company with experience elsewhere comes in and starts to suggest to do things better. You have a personality clash where the stubborn veteran guy will try to out the new person just so they don't have to learn anything.

    There are countless stories of a bright and eager junior getting politicked into quitting or being fired by a curmudgeon who doesn't want to adapt and doesn't want to be shown up but coast along doing the minimum.

  • Patrick (unregistered) in reply to Jared

    Most of the new grads might not have any clue of the field, but they are not the ones reading this site. I guess the conditional probability of a new grad reading TDWTF regularly and doing better than some long time developers is quite high. Of course, competing with the best long time developers is hard, but the stories on this site are not stories where only the best new grads and the best long time developers interact ...

  • Public Funk (unregistered)

    Gordon is that you.

  • chreng (unregistered) in reply to Public Funk

    Might be Paula

  • Gordian knot (unregistered)

    Ah, source control meets duct tape bailing twine and gum. Release engineering nowhere to be found

  • Corin (unregistered) in reply to Matt Westwood

    same. THIN ICE.

  • Confused (unregistered)

    I must be missing something. The note says "your reaction was much more interesting", but the 4th comment - the first one relevant - says the note was already there. So what reaction was it referring to?

  • Herby (unregistered)

    Sounds like he had a "buzzword boss". He got ahold of some software that satisfied his need for a buzzword, then used it in his own way which had no basis in reality. The boss just did it to use the buzzword.

    I suspect that the boss had no real experience in using a source control system in any way to manage a coherent design process.

    And so it goes.....

  • radarbob (unregistered) in reply to DocMonster

    Dang didilly ditto, DocMonster. And that is a situation you want the newbies to witness. Learn something, swear you'll never let this happen to you, and then get the hell out because you are the nail that will get hammered down.

  • radarbob (unregistered)

    P.S. A seminar speaker said "sometimes the best thing to happen to you is that you get fired." Years later I lived it. Not that I was stagnating absolutely, but just being there forces it upon you. But far, far, worse was the friction with their in-bred culture. On that purge day, many commented "you're the only one who is happy."

  • radarbob (unregistered) in reply to radarbob

    Boy I screwed that up. What I meant to say:

    P.S. A seminar speaker said "sometimes the worst thing is that you don't get fired." Years later I lived it. Not that I was stagnating absolutely, but just being there forces it upon you. But far, far, worse was the friction with their in-bred culture. On that purge day, many commented "you're the only one who is happy."

  • Robert Hanson (unregistered)

    I worked at a company once that actually required a convoluted system like this. We provided software that would be installed as part of a larger system that ran on various versions of a hardware platform (not just a computer system, but also peripherals, that were sold together as a unit). Because the hardware system was a significant investment for the user, it was not practical to have them upgrade once the system was purchased. So we supported not just the current version of the software, but maybe 5 versions back. So each time a bug was fixed, we'd fix it in the current dev branch; then go back to each of the old systems and either patch as is, or re-engineer the patch so that it was compatible with the old system.

    Then followed 5 rounds of regression testing, one for each of the 5 versions; this involved not only build/deploy the software but build out the hardware environment these were to run in.

    So yes, sometimes it makes sense to have not just one "main" branch, but many such "main" branches, one for each version of a product you're required to maintain for years.

  • Geoff (unregistered) in reply to Mike Dimmick

    Some times its simply indicative of code quality problems. I used to support an CRUD (not web) inventory/shipping application that could only be kindly described as a spaghetti code. Making any kind of change usually required spraying alterations across the entire application. It was born at a time when source control (at least for anything non mainframe) was not in use at the organization and put under source control for maintenance later. Since the application had no determinable architecture even refactoring was a lost cause. The only thing that could be done was a rewrite, there was just no saving it. Nobody wanted to make it an active project again though, so changes and fixes had to be made. Unfortunately some people also had processes that depended on broken behaviors which they were unwilling to change, so we had to have multiple versions where certain things were left broken so you could generate certain reports. Other operations had to be done in the fixed versions.

    So we did almost exactly what the article describes. Fortunately changes and updates were pretty infrequent.

  • Friedrice the Great (unregistered) in reply to Literary Critic

    My fav quote about Dan Brown was one I saw featured on the cover of a similar book by a different author: "Written like Dan Brown if Dan Brown could write."

  • GorGutz 'Ead 'Unta (unregistered)

    Well then, I realized what fresh hell this was when "Gordon" seemed to think that branches are supposed to be like actual branches. This is despite the fact that trees aren't supported by branches that get bigger as you go up.

  • Aatch (unregistered) in reply to Robert Hanson

    That's not quite the same. Having extra branches for backporting fixes makes sense. You're still just maintaining a single master branch, it's just per-version instead of per-project. There's also a clear "main" branch for landing new features, presumably. If you have to support multiple versions, I'm not sure if there's a much better way than how that company did it.

    Gordon's system on the hand... That's just madness incarnate.

  • TheCPUWizard (unregistered)

    There are times when supporting multiple versions over a long time (perhaps a decade or more) is the reality. There are also ways to organize the software so that it is maintainable under those conditions. Alas, the former is far more common than the latter making situations like this article (and comments) a frequent reality.

  • RRR (unregistered) in reply to Robert Hanson

    That's not the same thing as in the original story.

  • (nodebb) in reply to Mike Dimmick

    It felt slightly like a nightmare of continuously maintaining old versions of the software, which is a WTF in itself. Customers shouldn't stick on an old version of your software forever

    Painful: yes; WTF: no. When the company maintaining the software is also the company bearing the cost of constantly upgrading the installed units in the field (e.g. they deliver a turnkey system with a given LOS at a fixed contract payout), it suddenly becomes much more feasible to keep supporting and producing back-patches for the older versions.

  • Jeff (unregistered)

    I guess this is how they do software development in the Upside Down.

  • löchlein deluxe (unregistered)

    Well, they're called "branches" after all and branches don't usually grow back into the trunk. Maybe they should be called "bypass" instead, those do merge back. Or lay-by.

    What, silly? Me?

  • D8 (unregistered)

    Our source repository for 10 devs is a straight 20000 commit long line. Branches and pull requests are forbidden and heretical.

  • The Original Fritz (unregistered)

    Is the joke the fact that in this piece Remy Porter reveals himself to be literally "opinionated about style"?

  • John Meyer (google)

    I'm surprised he didn't hang himself for nine days to receive the knowledge of Branches.

  • (nodebb) in reply to D8

    Squash merges are a thing.

Leave a comment on “The World Tree”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article