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."
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.
-
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.
As I see it, there are three approaches to this problem: change it, learn to tolerate or at least ignore it, or leave so that it's no longer your problem. Leaving is a valid solution if you think the problem's intractable.
shiftedbitmonkey wrote:
Leaving is rarely the correct decision.
Why? Life's too short to spend your time working with asshats. While I grumble about the company I work for, my coworkers are a pretty good bunch of people. If they weren't, it would be a lot easier to consider moving on.
Software Zen:
delete this; -
As I see it, there are three approaches to this problem: change it, learn to tolerate or at least ignore it, or leave so that it's no longer your problem. Leaving is a valid solution if you think the problem's intractable.
shiftedbitmonkey wrote:
Leaving is rarely the correct decision.
Why? Life's too short to spend your time working with asshats. While I grumble about the company I work for, my coworkers are a pretty good bunch of people. If they weren't, it would be a lot easier to consider moving on.
Software Zen:
delete this;In the context of this post, he started this project in 1994. Don't you think leaving because of a couple of "asshats" is a bit too severe? Also considering the type of work he gets to do? Kind of elite, and probably not available just anywhere. I still contend that in the context of this thread leaving is not a viable suggestion. But that's just my opinion.
I've heard more said about less.
-
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."
-
Why be the hero and continually fix problems that shouldn't happen? Be less available, tell them its someone else's turn to unravel the mess. Sounds like you need some boss to decree that the others need to follow reasonable procedures. Suggest some.
CDMTJX wrote:
Sounds like you need some boss to decree that the others need to follow reasonable procedures.
decrees will not be done.
CDMTJX wrote:
Suggest some.
I have, but with everyone "peer" status there is little incentive to follow. Me and everyone on that list are equal in status. Folks look to me to rescue the day because of 16 years here, I am getting to be one of the old-timers.
CDMTJX wrote:
Be less available, tell them its someone else's turn to unravel the mess.
I have actually tried this, there is little incentive again to make it happen. The customers call me when there are problems, so I will fix it now or later. I remind everyone of my 2 month hospitalization in 2001, and follow up bed/house bound for first 2 months in 2002 following that. One of the employees remembers that because he HAD to cover for me. 4 months in my shoes is hard to forget. The others haven't experienced that. They even called me in the desert on the way back from california during my vacation.
_________________________ 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."
-
In the context of this post, he started this project in 1994. Don't you think leaving because of a couple of "asshats" is a bit too severe? Also considering the type of work he gets to do? Kind of elite, and probably not available just anywhere. I still contend that in the context of this thread leaving is not a viable suggestion. But that's just my opinion.
I've heard more said about less.
shiftedbitmonkey wrote:
In the context of this post, he started this project in 1994. Don't you think leaving because of a couple of "asshats" is a bit too severe? Also considering the type of work he gets to do? Kind of elite, and probably not available just anywhere.
You are both correct in some respects. THAT is why I am venturing out on my own. Slowly but surely.
_________________________ 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."
-
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 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...
Time to beam out to a transport and travel to a new company...I'm a standards-oriented person with respect to source control...admittedly, I don't like branch/merge because I have yet to see one that worked well enough to use that wouldn't corrupt it's own database eventually...but every company I've worked for that failed to get a tight grip on source control wound up paying for it, in gold and blood...and I believe I infer correctly that you work with a bunch of developers who need a good kick in the ass, or a new team-leader with gumption.
-
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
Marc Clifton wrote:
Hehe. I've been reworking some C++ code for client (I'm a rocket scientist again, sort of ) that resurrected a project 8 years old. OMG. It's so wierd going back to C++. I hope I don't go schizo.
Don't be afraid :laugh: it's not that you're schizophrenic, it's that you've repressed for so long your inner Real Programmer.
-
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...)
Thelly wrote:
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
I actually highly recommend VisualSVN[^]. It handles renaming/deleting very well.
-
When you think about it, nobody likes to tell the person above them about problems. So, the CEO is being "protected" from bad news by everybody below him. He couldn't tell you if it was raining if he looked out the window.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
When you think about it, nobody likes to tell the person above them about problems. So, the CEO is being "protected" from bad news by everybody below him. He couldn't tell you if it was raining if he looked out the window.
One has to keep in mind that the suckups get closer to power by assuming responsibility for handling problems. No one in the suckup layer wants people below them reporting problems to the power, as this will threaten their position. The best way to solve this is for those in power to have their own intelligence system monitoring their domain, one that bypasses any layer of suckups.
-
Todd Smith wrote:
Do you have a QA department or release manager?
Not for 10 years! he was laid off at the last lay off. I am the QA, mostly because this is my "baby" I started it all on my own in 1994 when no one thought it could be done, and especially not by some no-body kid without any edjumakation! I was just a hick kid from a hick town in NM, with a tech certificumacation from a hick school in hick-town oklahoma (Tulsa). :) I have pride in this work, so I am Scotty, and QA.
El Corazon wrote:
Todd Smith wrote: Do you have a QA department or release manager? Not for 10 years! he was laid off at the last lay off. I am the QA, mostly because this is my "baby" I started it all on my own in 1994 when no one thought it could be done, and especially not by some no-body kid without any edjumakation! I was just a hick kid from a hick town in NM, with a tech certificumacation from a hick school in hick-town oklahoma (Tulsa). I have pride in this work, so I am Scotty, and QA.
They have you by your pride. Been there...you have my sympathy, but I recommend you go find someone to work for that you can be proud of.