I give up... more source control...
-
OK OK, it's easy. You look at him with those helpless kitten eyes, lean forwards so he isn't looking at your face, say in a soft husky voice "There is something I'd like you to do for me.", lean back and smile slightly then... Go into full PMT ninja mode and scream "Check in the code when you're told and after you've checked the build works or you'll get the same as the last guy! :mad: :laugh: Just don't ask me what happened to the last guy :-O
Visit http://www.notreadytogiveup.com/[^] and do something special today.
Trollslayer wrote:
Just don't ask me what happened to the last guy
He probably got promoted... X| X|
-
We have one programmer who wants it kept a file system with directory structure that is nested almost as deep as his code, doesn't like branch/merge and prefers all tools to be command line. Another submits all the time and breaks the build at least once a week (and is on vacation after making one such fatal commit before leaving). Another who submits rarely complaining that svn doesn't act enough like VSS and when it does he will do it more. A few others do what ever they want because they don't share and don't team, and will not either. yet when there is a problem, I am supposed to be "Scotty" and get everything fixed. I don't want this trouble. If my company was only doing good enough to pay health insurance... gonna hide in my office for fifteen minutes before I shift to Scotty mode. I need a (tm)Trollslayer method for dealing with teams... I wonder if she'll contract out to teach the (tm)Trollslayer method.... *sigh*
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
The team interaction here is severely broken. You either need to get upper-level management to crack the whip and force the issue, or leave. If you have well-defined source management practices and any kind of reasonable tool for source control, there's absolutely no excuse for the kind of prima donna behavior you're getting. Maybe instead of "Scotty" mode you need to go into "Worf" mode instead :-D.
El Corazon wrote:
I need a (tm)Trollslayer method for dealing with teams
I would recommend hanging a katana[^] on your office wall. The placard below should read:
"In case of a broken build, apply as needed"
This would work well with the aforementioned "Worf" mode.
Software Zen:
delete this; -
Pete O'Hanlon wrote:
It's MTL - Marc's Trashing Language.
Hehe. I've been reworking some C++ code for client (I'm a rocket scientist again, sort of :jig: ) that resurrected a project 8 years old. OMG. It's so wierd going back to C++. I hope I don't go schizo. Marc
How can I use that dancing gif? :) :-D :laugh: ;) ;P :^) :( :sigh: :doh: :(( :zzz: :-\ :-O :rolleyes: :omg: :wtf: :mad::confused::~ :| X| :suss::cool::rose:
It is said that the most complex structures built by mankind are software systems. This is not generally appreciated because most people cannot see them. Maybe that's a good thing because if we saw them as buildings, we'd deem many of them unsafe.
-
We have one programmer who wants it kept a file system with directory structure that is nested almost as deep as his code, doesn't like branch/merge and prefers all tools to be command line. Another submits all the time and breaks the build at least once a week (and is on vacation after making one such fatal commit before leaving). Another who submits rarely complaining that svn doesn't act enough like VSS and when it does he will do it more. A few others do what ever they want because they don't share and don't team, and will not either. yet when there is a problem, I am supposed to be "Scotty" and get everything fixed. I don't want this trouble. If my company was only doing good enough to pay health insurance... gonna hide in my office for fifteen minutes before I shift to Scotty mode. I need a (tm)Trollslayer method for dealing with teams... I wonder if she'll contract out to teach the (tm)Trollslayer method.... *sigh*
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
El Corazon wrote:
We have one programmer who wants...
Only One?!?! ;) We have people like the one's you speak of. To them, it's always "Easier" to keep code on there disk and not check it in. And when they check it in, something breaks because they're changing other peoples code they use and not checking it in. We put it on their yearly objectives to check in once a week, to get with others about changing their code, and to not break the build over 10% of the time (still hight but lower than the 50% build/break/check in pace they've been at.) They [all] have failed to meet their objective and it really doesn't matter to the company, the program wants head count! It doesn't matter if it's more work for everyone else. All I can say is welcome to the Large, insensative corprate world
-
Your team needs therapy. Kjetil
Kjetil Svendsen wrote:
Your team needs therapy.
"Group" Therapy? ;)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
The team interaction here is severely broken. You either need to get upper-level management to crack the whip and force the issue, or leave. If you have well-defined source management practices and any kind of reasonable tool for source control, there's absolutely no excuse for the kind of prima donna behavior you're getting. Maybe instead of "Scotty" mode you need to go into "Worf" mode instead :-D.
El Corazon wrote:
I need a (tm)Trollslayer method for dealing with teams
I would recommend hanging a katana[^] on your office wall. The placard below should read:
"In case of a broken build, apply as needed"
This would work well with the aforementioned "Worf" mode.
Software Zen:
delete this;Gary Wheeler wrote:
Maybe instead of "Scotty" mode you need to go into "Worf" mode instead
I always wanted a bat'leth, I may have to make it. Oh the forms I could do with that baby. I miss my weapon collection somedays.
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
He who breaks the evening build buys donuts for the team the next day.
MrPlankton
Even better: he who breaks the evening build leads the 10K run the next day.
Software Zen:
delete this; -
How can I use that dancing gif? :) :-D :laugh: ;) ;P :^) :( :sigh: :doh: :(( :zzz: :-\ :-O :rolleyes: :omg: :wtf: :mad::confused::~ :| X| :suss::cool::rose:
It is said that the most complex structures built by mankind are software systems. This is not generally appreciated because most people cannot see them. Maybe that's a good thing because if we saw them as buildings, we'd deem many of them unsafe.
colon jig colon No spaces between ':' and the word "jig". Marc
-
El Corazon wrote:
We have one programmer who wants...
Only One?!?! ;) We have people like the one's you speak of. To them, it's always "Easier" to keep code on there disk and not check it in. And when they check it in, something breaks because they're changing other peoples code they use and not checking it in. We put it on their yearly objectives to check in once a week, to get with others about changing their code, and to not break the build over 10% of the time (still hight but lower than the 50% build/break/check in pace they've been at.) They [all] have failed to meet their objective and it really doesn't matter to the company, the program wants head count! It doesn't matter if it's more work for everyone else. All I can say is welcome to the Large, insensative corprate world
There's no reason for the kind of nonsense you're describing. At the company I work for, engineering management is entirely hardware folks. None of them give a crap how we develop software. All they care about is that when we deliver it, it works. Based on this, there's no reinforcement from above if we've got an engineer who won't cooperate with source control. As a result, we have to provide it ourselves. The primary incentive is that our build process is entirely automated. You log into the build machine, double-click on the icon on the desktop for the product and branch you want to build, enter a build comment in the dialog if you want, and click the Build button. The machine chugs for 45-75 minutes, and dumps out a formatted build log and an archive DVD (if the build was successful). It can't get any simpler. The only requirement of the engineer is that their code is checked into source control. Even our most recalcitrant geezer (not me, but I'm close) gets it and cooperates with the process. If we have broken builds, they're far more likely to be :doh: moments rather than somebody being X|.
Software Zen:
delete this; -
colon jig colon No spaces between ':' and the word "jig". Marc
Wee, thanks! :jig:
It is said that the most complex structures built by mankind are software systems. This is not generally appreciated because most people cannot see them. Maybe that's a good thing because if we saw them as buildings, we'd deem many of them unsafe.
-
We have one programmer who wants it kept a file system with directory structure that is nested almost as deep as his code, doesn't like branch/merge and prefers all tools to be command line. Another submits all the time and breaks the build at least once a week (and is on vacation after making one such fatal commit before leaving). Another who submits rarely complaining that svn doesn't act enough like VSS and when it does he will do it more. A few others do what ever they want because they don't share and don't team, and will not either. yet when there is a problem, I am supposed to be "Scotty" and get everything fixed. I don't want this trouble. If my company was only doing good enough to pay health insurance... gonna hide in my office for fifteen minutes before I shift to Scotty mode. I need a (tm)Trollslayer method for dealing with teams... I wonder if she'll contract out to teach the (tm)Trollslayer method.... *sigh*
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Even Microsoft doesn't use VSS (even after they rewrote it "so that it wasn't crap")...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
There's no reason for the kind of nonsense you're describing. At the company I work for, engineering management is entirely hardware folks. None of them give a crap how we develop software. All they care about is that when we deliver it, it works. Based on this, there's no reinforcement from above if we've got an engineer who won't cooperate with source control. As a result, we have to provide it ourselves. The primary incentive is that our build process is entirely automated. You log into the build machine, double-click on the icon on the desktop for the product and branch you want to build, enter a build comment in the dialog if you want, and click the Build button. The machine chugs for 45-75 minutes, and dumps out a formatted build log and an archive DVD (if the build was successful). It can't get any simpler. The only requirement of the engineer is that their code is checked into source control. Even our most recalcitrant geezer (not me, but I'm close) gets it and cooperates with the process. If we have broken builds, they're far more likely to be :doh: moments rather than somebody being X|.
Software Zen:
delete this;Gary Wheeler wrote:
There's no reason for the kind of nonsense you're describing.
You're completly correct, this is stupid behaviour. But we're run by bean counters and bureaucratic processes...not engineering
-
Even better: he who breaks the evening build leads the 10K run the next day.
Software Zen:
delete this;Gary Wheeler wrote:
Even better: he who breaks the evening build leads the 10K run
slow gasping staggerthe next day.fixed that for you. :rolleyes:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Gary Wheeler wrote:
There's no reason for the kind of nonsense you're describing.
You're completly correct, this is stupid behaviour. But we're run by bean counters and bureaucratic processes...not engineering
I was trying to point out that this is an issue you can resolve yourselves. Part of the key in our case was to make the build process drop-dead easy as long as you cooperate with the source control policy. If your build process is a PITA, requiring a lot of manual operations or data not pulled from source control, there's far less obvious need to use source control as the repository for everything that goes into the build. In our case, everything that goes into the build either lives in the source control system or on the build machine itself.
Software Zen:
delete this; -
Gary Wheeler wrote:
Even better: he who breaks the evening build leads the 10K run
slow gasping staggerthe next day.fixed that for you. :rolleyes:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
Either your builds get fixed and stop breaking, or your staff become healthier and more fit and therefore more productive. It's a win either way ;).
Software Zen:
delete this; -
I was trying to point out that this is an issue you can resolve yourselves. Part of the key in our case was to make the build process drop-dead easy as long as you cooperate with the source control policy. If your build process is a PITA, requiring a lot of manual operations or data not pulled from source control, there's far less obvious need to use source control as the repository for everything that goes into the build. In our case, everything that goes into the build either lives in the source control system or on the build machine itself.
Software Zen:
delete this;Gary Wheeler wrote:
I was trying to point out that this is an issue you can resolve yourselves.
It's not as easy as that. I'm not backed up by management. We are required (by management) to use an archaic source control system (Razor) which isn't that easy. I've tried to take as many manual steps out. I've gone to Verification with broken code and incomplete code (becasue it's not checked int) to try and raise the issues of this but the Program manager only say "try again when you're ready". I herd the cats to get it ready. If we fail again he would just say "try again when you're ready". He would not back me up in any type of enforcement of the policies. My goal right now is to move on to another project. I might just switch projects and see if anyone cares.
-
We have one programmer who wants it kept a file system with directory structure that is nested almost as deep as his code, doesn't like branch/merge and prefers all tools to be command line. Another submits all the time and breaks the build at least once a week (and is on vacation after making one such fatal commit before leaving). Another who submits rarely complaining that svn doesn't act enough like VSS and when it does he will do it more. A few others do what ever they want because they don't share and don't team, and will not either. yet when there is a problem, I am supposed to be "Scotty" and get everything fixed. I don't want this trouble. If my company was only doing good enough to pay health insurance... gonna hide in my office for fifteen minutes before I shift to Scotty mode. I need a (tm)Trollslayer method for dealing with teams... I wonder if she'll contract out to teach the (tm)Trollslayer method.... *sigh*
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Well, command-line guy is easy, just don't let him know about any of the UI tools for SVN and make *him* write the hook script to transform the actual code structure into his perverse collection of nested directories and back again. Tell him he's "allowed" to do that if he handles the branching and merging, if he still refuses after being told he can have most of his cake, find a window on the top floor that looks a little shaky. Build-breaker needs to start buying lunch, and someone suggested a script to build-on-commit, this is quite important as it can then broadcast an e-mail with the name, extension, cube location, and favorite tele-tubby of the offending submitter. If it is still a problem after a couple weeks, make sure they haven't fixed that window too well. I don't know what you are using for code editing but the VSS guy sounds like a Visual Studio user. You can try AnkhSVN (I don't like dev evnvironment integration all /that/ much but it is nice for renaming files, that's the one thing that's clunky with Tortoise in a Studio project) with him, if his complaint is that it doesn't lock files by default or something... make sure nobody's thought to put a safety net under that window. The "I'll take my ball" crowd should start being treated like off-site subs or outsourcers- they can do whatever they want and hand over working objects + source at their deadlines. If they lose something they get to have a fun night finding/rewriting it and it damn well better still work. (it sounds like you're in a kind of "build master" role where you take the code and create the deliverable output... you should check with your management to see how *they* would react if you started demanding things be corrected when someone breaks the build rather than fixing them yourself as it sounds is happening now. If management would rather you do the rest of the team's job for them, start looking... but if you can get your boss to agree that people are wasting time like crazy because they won't listen to a little common sense... that's a BIG lever to have when you sit everyone down and formalize the source control/build procedures. It is an even bigger club to have sitting nearby when you have to enforce them...)
-
Gary Wheeler wrote:
I was trying to point out that this is an issue you can resolve yourselves.
It's not as easy as that. I'm not backed up by management. We are required (by management) to use an archaic source control system (Razor) which isn't that easy. I've tried to take as many manual steps out. I've gone to Verification with broken code and incomplete code (becasue it's not checked int) to try and raise the issues of this but the Program manager only say "try again when you're ready". I herd the cats to get it ready. If we fail again he would just say "try again when you're ready". He would not back me up in any type of enforcement of the policies. My goal right now is to move on to another project. I might just switch projects and see if anyone cares.
Joe Q wrote:
My goal right now is to move on to another project
I agree. Your current project is doomed.
Software Zen:
delete this; -
Joe Q wrote:
My goal right now is to move on to another project
I agree. Your current project is doomed.
Software Zen:
delete this;Gary Wheeler wrote:
I agree. Your current project is doomed.
Yes, it is. And I'm pretty sure the PM and most of his top guys are going to retire by the end of the year. (Rats deserting a sinking ship?)
-
The team interaction here is severely broken. You either need to get upper-level management to crack the whip and force the issue, or leave. If you have well-defined source management practices and any kind of reasonable tool for source control, there's absolutely no excuse for the kind of prima donna behavior you're getting. Maybe instead of "Scotty" mode you need to go into "Worf" mode instead :-D.
El Corazon wrote:
I need a (tm)Trollslayer method for dealing with teams
I would recommend hanging a katana[^] on your office wall. The placard below should read:
"In case of a broken build, apply as needed"
This would work well with the aforementioned "Worf" mode.
Software Zen:
delete this;Gary Wheeler wrote:
, or leave.
Seems a lot of people like to advocate this solution. Doesn't seem practical if you've devoted 12 years to a project and you just have to deal with some obstinate folk. Leaving is rarely the correct decision. I'd wager that you could find reasons to "just leave" from every job out there. Come on folks, get creative with your armchair philosophy.
I've heard more said about less.