I give up... more source control...
-
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."
Your team needs therapy. Kjetil
-
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."
Dont know if I understand correctly, but already had a look on Visual Studio Team System (Server)? ... there are some good webcasts out there.
-
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."
Hi, I am not more than a non productive student but I know that managing a team and working with it is a real challenge. What I can say when reading your post is that if there are problems when committing code between each module, it means that those modules are too coupled, therefore the problem could come from analysis. As said above, you should also certainly spend some time with your "team" in order to build a consistent method and a consistent Team.
Let's make code sharing our goal... Blaise Braye
-
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."
Others have said it I know, but you need to get the procedure agreed. Not because 'this is the way to do it', but because of the 'this is why we do it'. With a code repository you have a single point to back-up and that's it, all the company's code lines are safe. Multiple developers can work on the same version of a file and then safely merge them. We run a main line for all development and then branches for releases and each built is labeled so it can be re-created. You can have a build process that automatically builds latest (development) and labeled (release) images from the source repository. It is in the interest of the developers to use, and to use well, which ever repository is in use. Failure to use it is damaging to the Company and in the end to there prospects. Close the debate with the better the quality, including auditable history, of the code is, then the less money will need to be spent finding and fixing problems. With less money SPENT, there is more to PAY!
Panic, Chaos, Destruction. My work here is done.
-
El Corazon wrote:
prefers all tools to be command line
And apparently doesn't know how to use the 'Net, since SVN has plenty of good command line tools. :rolleyes:
El Corazon wrote:
Another submits all the time and breaks the build at least once a week
Have you considered setting up build scripts that roll back the last revision whenever the build breaks? :~
El Corazon wrote:
Another who submits rarely complaining that svn doesn't act enough like VSS and when it does he will do it more.
Tell him he can go back to using VSS when he trades in his PC for this computer[^]. I'm sure VSS works just fine with it. :-\
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
Shog9 wrote:
doesn't know how to use the 'Net, since SVN has plenty of good command line tools
What SVN has to do with .NET? And who needs command line tools if there is TortoiseSVN.net ? (Or are we talking Linux? Tortoise is Win only :-\ )
-
Shog9 wrote:
doesn't know how to use the 'Net, since SVN has plenty of good command line tools
What SVN has to do with .NET? And who needs command line tools if there is TortoiseSVN.net ? (Or are we talking Linux? Tortoise is Win only :-\ )
Shog means the internet. It's not so easy surfing via the command line!
-
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;