Don't worry, I'll just refactor it some more



  • We deploy our application in six jars: common, data wrappers, wsdl (public data structures), db layer, util and main application.

    A new guy on our team is busy trying to migrate us from a simple hierarchy of ant/build.xml to one of the automated build tools. One of the contracts he made with my boss was that nothing external to what he was doing would need to change; no classpaths; no scripts; nothing.

    In the process, he decided things needed to be refactored in order to fit in with the tools' methodology. My boss tells him to Drink the Koolade, but don't go too far because we don't want to restructure our application tree (actually it needs refactoring, but when you make your case and the boss explicitly says don't, you should listen).

    Three weeks later, the build starts failing. Apparently, the guy started checking in his stuff. Although it worked for him in his half-migrated setup, his refactoring didn't sit well with the existing build system still in use by everyone else. After a week of this, he finally got it semi stable.

    It turns out that he split lots of libraries up into different sub libraries and so forth. We now have 22 jars that have the form: xxx-X.Y.Z-CANNEDLABEL.jar where x, y and z are version numbers that change with every compile. For every developer. Plus the automated build. Hmmm, that's gonna be a problem for the run-scripts. I told the guy to use the versioned jar names for internal auditing, but to change the names back to the original file names when copying to the deploy directory. He refused.

    A little more digging and it turns out that when he split certain jars into multiple projects, he didn't take into account classes that are used by multiple sub projects. So now he wants to go and add common projects for each of the sub projects, which will yield over 30 jars - with unpredictable file name formats.

    I can write a script that can work with it, but my boss just wants everything put back the way it was.

    We have a team meeting to discuss it.

    Ten people (including my boss) are bitching that things we all agreed would not change have been changed. But the tool requires that we work this way. Erm, no it doesn't; it's just that you prefer to work this way; put it back. Don't worry, I'll just refactor it some more...



  • So if I am understanding you correctly, your boss is doing the right thing with the only exception of not actually exerting his authority, that is a wtf right there.  If I had some degree of seniority and the guy was checking in code that broke the build, I would keep rolling back his changes.  The other solution when doing something like this is to have a separate development stream just for him, so he can break, mess up, and mangle all the code he wants without hurting the rest of you. If he -finally- gets it to 'work', then you can review his code and proceed to mock and ridicule him to no end and refuse to merge it in until he does his job correctly.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    On a side note snoofle, I love your stories.


  • ♿ (Parody)

    I want to fight the new guy.

    Also, a great example of why you should do stuff like this in a branch.



  • @boomzilla said:

    I want to fight the new guy.

    Also, a great example of why you should do stuff like this in a branch.

    I had created a dedicated branch for him to do this. He did it in the dedicated branch. Then he said that he got it to work. My boss blindly trusted him (major wtf right there) and told him to merge it into the trunk branch. That's when the build hit the fan.

     


  • ♿ (Parody)

    @snoofle said:

    I had created a dedicated branch for him to do this. He did it in the dedicated branch. Then he said that he got it to work. My boss blindly trusted him (major wtf right there) and told him to merge it into the trunk branch. That's when the build hit the fan.

    Oops. Yep, at minimum, some peer review. Ideally, also a demonstration from a clean environment by someone else. Of course, the review should have shown how he shat all over the boss' directions, preventing the need for a demonstration.

    Oh, well, at least we got another good WTF out of you.



  • Wow. A surprisingly mellow WTF this time around :) One I can finally relate to and proof that Snoofle does on fact live on earth in stead of some corner of hell reserved especially for the IT crowd.



  • Are some of these new tools Jenkins/Hudson, Sonar, or Nexus (all Java)? Because our client's "architect" is trying to make us go the same route, except our code is .NET and we've already had to change our project because apparently Sonar (code analysis) can't handle projects with the same name, even if they're in different physical locations. Which only serves to reinforce my belief that Java is shit.

    Also your boss seems to have trust issues with new people... in that he trusts them too easily.


  • ♿ (Parody)

    @The_Assimilator said:

    ...apparently Sonar (code analysis) can't handle projects with the same name, even if they're in different physical locations. Which only serves to reinforce my belief that Java is shit.

    I know, right? One time, at band camp...



  • @snoofle said:

    I had created a dedicated branch for him to do this. He did it in the dedicated branch. Then he said that he got it to work. My boss blindly trusted him (major wtf right there) and told him to merge it into the trunk branch. That's when the build hit the fan.
    Wouldn't it have been possible (and safer) to first reverse-merge the trunk into the experimental branch, and only if that would have gone off without a hitch, promote the branch to the new trunk?



  • @Anonymouse said:

    @snoofle said:

    I had created a dedicated branch for him to do this. He did it in the dedicated branch. Then he said that he got it to work. My boss blindly trusted him (major wtf right there) and told him to merge it into the trunk branch. That's when the build hit the fan.
    Wouldn't it have been possible (and safer) to first reverse-merge the trunk into the experimental branch, and only if that would have gone off without a hitch, promote the branch to the new trunk?

     

    You mean perform release management which requires more than just pushing some buttons?

     


Log in to reply