"You know you're a Version Control Avoider if..."
-
"Version Control Subversive"
-
/re-start preach /harsh mode If I was doing this according to my own rules, I would not be preaching :-) I would be asking you a question then saying: Tell me more. Anywho... Knock knock: We have great double glazing on a 50% sales offer. You: So do I, it's free, bye. Knock, knock: Tell me about why you have double glazing? You: Because it keeps my house warm, my heating bills down, it doesn't have condensation all winter. Salesman: Tell me more You: Blah, blah Salesman: What if you could have a double glazed window that saved even more on your heating bills? You: How much would it save me and how much does it cost? He's in, you're talking, he hasn't sold you anything you didn't ask for. He hasn't said 'and it refelcts heat out in the summer to keep air-con bills down', you didn't ask for it. Selling is hard prep work and easy once you've prep'ed. Very tough otherwise, unless your audience is already begging for your product. Compare... Them: Our 'system' works good enough; why change it? <-- Their view You: even though it doesn't support diffing or branching or merging or coordinated collaboration <-- Your view You: It's not that they are resistant so much as they are unaware of the benefits of VCS <-- Your view of the benefits needs to be put into their words, what are their AFTER's? Yours are irrelevant. You: help them see some of the drawbacks of their current mechanisms <-- 'help them see', your view, not theirs You: not for my sake, but because I really believe it is going to help make THEIR lives easier <-- 'I really believe', what do they believe? Nothing else is relevent to a selling job Also, they are resistant, 'Our 'system' works good enough; why change it?', that's resistance. Sorry, harsh (really, sorry), but if they are at all resistant (and few folk like change so there will be resistance even if not expressed openly) the best you can hope for is 'we'll give it a try', which will only work for you if it shows THEM benefits THEY want very quickly which is tough when they are adopting new practices and behaviours, they'll miss the benefits because they are fighting with new ideas, concepts and an unfamiliar software tool (or command line). What will make them stick at it when it gets difficult to use a totally new system if they aren't doing it because they are bought in on their terms? Them: Our 's
Ever had a company come and do a 'cold call' / uninvited pitch? Normally they give a presentation about themselves, who they are, how many staff they have, who they work with, their successful products, how many offices they have etc? They are selling their product to you based on what they beleive makes it great. What about this though; they turn up with no powerpoint and start off by saying 'What would make your life easier and better?', 'What do you want to help your business grow?' You answer, they then pitch their business only on how they can help you achieve things you've asked for. Every single minute of the meeting is relevant to you, you talked and they talked back only with reference to what you asked for. In the first approach the other company hoped that what they were selling coincided with something you wanted or didn't realise you wanted. In the second approach they only tried to sell you what you'd already asked for. I'd prefer to be in the second business, we'd be far more likely to succeed since our approach is based on selling only what people already want not on hope and good luck, timing. I have personal (very good) experience of both approaches, the second one is orders of magnitude more effective but tough to do. Humans like to talk about themselves and why they think they are great, what makes their company or product great, it's natural. We also like to sell by convincing, it's easier, we understand why we want / like something, it's harder to understand what someone else wants or likes (otherwise dating would be much easier) and then to sell what we have in those terms not ours (in which case I'd have 3 dates a night). Good luck. Mike
-
/re-start preach /harsh mode If I was doing this according to my own rules, I would not be preaching :-) I would be asking you a question then saying: Tell me more. Anywho... Knock knock: We have great double glazing on a 50% sales offer. You: So do I, it's free, bye. Knock, knock: Tell me about why you have double glazing? You: Because it keeps my house warm, my heating bills down, it doesn't have condensation all winter. Salesman: Tell me more You: Blah, blah Salesman: What if you could have a double glazed window that saved even more on your heating bills? You: How much would it save me and how much does it cost? He's in, you're talking, he hasn't sold you anything you didn't ask for. He hasn't said 'and it refelcts heat out in the summer to keep air-con bills down', you didn't ask for it. Selling is hard prep work and easy once you've prep'ed. Very tough otherwise, unless your audience is already begging for your product. Compare... Them: Our 'system' works good enough; why change it? <-- Their view You: even though it doesn't support diffing or branching or merging or coordinated collaboration <-- Your view You: It's not that they are resistant so much as they are unaware of the benefits of VCS <-- Your view of the benefits needs to be put into their words, what are their AFTER's? Yours are irrelevant. You: help them see some of the drawbacks of their current mechanisms <-- 'help them see', your view, not theirs You: not for my sake, but because I really believe it is going to help make THEIR lives easier <-- 'I really believe', what do they believe? Nothing else is relevent to a selling job Also, they are resistant, 'Our 'system' works good enough; why change it?', that's resistance. Sorry, harsh (really, sorry), but if they are at all resistant (and few folk like change so there will be resistance even if not expressed openly) the best you can hope for is 'we'll give it a try', which will only work for you if it shows THEM benefits THEY want very quickly which is tough when they are adopting new practices and behaviours, they'll miss the benefits because they are fighting with new ideas, concepts and an unfamiliar software tool (or command line). What will make them stick at it when it gets difficult to use a totally new system if they aren't doing it because they are bought in on their terms? Them: Our 's
MadBadger (that's quite a nickname!), Thanks again. Really. I don't mind harsh. I've learned to appreciate thoughtful criticism, and yours in particular is quite thought-provoking. But.. > "If I was doing this according to my own rules, I would not be preaching > I would be asking you a question then saying: Tell me more." ...and if you had, I would have told you that I was hired recently and invited to observe -- as a consultant, more or less -- and to provide suggestions as to how they could better achieve their goals (This, after they very nearly lost a year's worth of coding efforts). So after several months of asking questions and observing their methods, I'm ready to offer some feedback. I'm not "selling" in the sense that I won't get any kickbacks of any sort if they don't "buy". (However, in an ironic sort of way, the fact that you didn't ask for my backstory pre-sermon really illustrated to me in a poignant way that it doesn't matter if *I* think I'm listening -- if THEY don't think I'm listening, then I haven't done my prep work.) Anyway, you have given me some excellent thoughts to chew on. Thank you very much for your time. (Actually, I'd like to say "Please tell me more", but you've invested enough time already!)
-
MadBadger (that's quite a nickname!), Thanks again. Really. I don't mind harsh. I've learned to appreciate thoughtful criticism, and yours in particular is quite thought-provoking. But.. > "If I was doing this according to my own rules, I would not be preaching > I would be asking you a question then saying: Tell me more." ...and if you had, I would have told you that I was hired recently and invited to observe -- as a consultant, more or less -- and to provide suggestions as to how they could better achieve their goals (This, after they very nearly lost a year's worth of coding efforts). So after several months of asking questions and observing their methods, I'm ready to offer some feedback. I'm not "selling" in the sense that I won't get any kickbacks of any sort if they don't "buy". (However, in an ironic sort of way, the fact that you didn't ask for my backstory pre-sermon really illustrated to me in a poignant way that it doesn't matter if *I* think I'm listening -- if THEY don't think I'm listening, then I haven't done my prep work.) Anyway, you have given me some excellent thoughts to chew on. Thank you very much for your time. (Actually, I'd like to say "Please tell me more", but you've invested enough time already!)
Ha, proved my own point backwards. A bit dum, but c'est la vie. Equally makes the point about how humans prefer to behave (the reply to my own message), tough habit to break. I'd recommend buying Andy's book, The Jelly Bean Effect, worth the price, lots of this stuff in there, presented far better than I have. Mike
-
Not a joke, but at my last company they did have production go down, and the backup was overwritten with the broken production, so the entire 500,000 lines of SQL stored procedures were lost. Or, they would have been if a coworker hadn't made a personal backup. Instead of fixing the situation (version control, off site backups, hardware that isn't ancient, employees that aren't tards, etc.), they put her in charge of backups. :doh:
AspDotNetDev wrote:
Instead of fixing the situation (version control, off site backups, hardware that isn't ancient, employees that aren't tards, etc.), they put her in charge of backups
No good deed goes un-punshished. She will never make that mistake again. She will continue to have backups of her work, but will take an appropriate amount of time to re-invent her things. :doh:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
Think inside the box! ProActive Secure Systems
I'm on-line therefore I am. JimmyRopes -
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
you comment out your code instead of deleting it?! ;-)
-
you comment out your code instead of deleting it?! ;-)
Hahahah! My dad does that! At every single opportunity that I have, I tell him about benefits of VCS, specifically GIT :cool:
-
/re-start preach /harsh mode If I was doing this according to my own rules, I would not be preaching :-) I would be asking you a question then saying: Tell me more. Anywho... Knock knock: We have great double glazing on a 50% sales offer. You: So do I, it's free, bye. Knock, knock: Tell me about why you have double glazing? You: Because it keeps my house warm, my heating bills down, it doesn't have condensation all winter. Salesman: Tell me more You: Blah, blah Salesman: What if you could have a double glazed window that saved even more on your heating bills? You: How much would it save me and how much does it cost? He's in, you're talking, he hasn't sold you anything you didn't ask for. He hasn't said 'and it refelcts heat out in the summer to keep air-con bills down', you didn't ask for it. Selling is hard prep work and easy once you've prep'ed. Very tough otherwise, unless your audience is already begging for your product. Compare... Them: Our 'system' works good enough; why change it? <-- Their view You: even though it doesn't support diffing or branching or merging or coordinated collaboration <-- Your view You: It's not that they are resistant so much as they are unaware of the benefits of VCS <-- Your view of the benefits needs to be put into their words, what are their AFTER's? Yours are irrelevant. You: help them see some of the drawbacks of their current mechanisms <-- 'help them see', your view, not theirs You: not for my sake, but because I really believe it is going to help make THEIR lives easier <-- 'I really believe', what do they believe? Nothing else is relevent to a selling job Also, they are resistant, 'Our 'system' works good enough; why change it?', that's resistance. Sorry, harsh (really, sorry), but if they are at all resistant (and few folk like change so there will be resistance even if not expressed openly) the best you can hope for is 'we'll give it a try', which will only work for you if it shows THEM benefits THEY want very quickly which is tough when they are adopting new practices and behaviours, they'll miss the benefits because they are fighting with new ideas, concepts and an unfamiliar software tool (or command line). What will make them stick at it when it gets difficult to use a totally new system if they aren't doing it because they are bought in on their terms? Them: Our 's
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
The version control aversion syndrome
-
Not a joke, but at my last company they did have production go down, and the backup was overwritten with the broken production, so the entire 500,000 lines of SQL stored procedures were lost. Or, they would have been if a coworker hadn't made a personal backup. Instead of fixing the situation (version control, off site backups, hardware that isn't ancient, employees that aren't tards, etc.), they put her in charge of backups. :doh:
IMO, that qualifies for a (horrible, dark-humored) joke.
-
Not quite a direct answer, but assuming from your question that you expect resistance and noting the phrase 'persuasive explanation' I would advocate a different approach from that which is suggested by your post, apologies if I am preaching to the converted. A great way (there is more than one and none are de facto best, it's situational) is that advocated by Andy Bounds, you'll have to hunt for hard content since he makes his money by selling books and appearances, not free content on teh intarweb. Essentially you don't convince, at least not from your perspective, you sell from their perspective. Or, you put it a different way, the reasons you want to use VC are irrelevant to your audience. What version control can do for them from their persepective is. So, why don't they use it today? Do you know all the reasons; why they prefer what they are doing? Etc. Tip: It's not because they don't understand, that's your perspective. If you don't know then mneeting 1 is you asking questions and listening, about 90% listening and 10% talking for you, only maybe less talking from you. The most common things you say should be 'Tell me more' and 'Do I understand this correctly, I think you said...'. Meeting 2 is VC from their perspective using what you learned to put it in their perspective. Powerpoint may be totally unnecessary. How does VC give them something they want? (AFTER's) What they want is defined by what they tell you in that first meeting or smaller discussions ahead of that meeting. Every point you want to make has to be a direct ansewer to what they've told you. If it isn't then don't say it, they aren't interested, no matter how important it is to you, it will dilute your direct answers to their actual questions and interests. /end preach :-) Mike
To put it another way, from their point of view you're trying to implement a solution to a problem that doesn't exist. Dig deep enough, and you'll find the problems they live with and consider normal. Then sell your solution to those problems. In small teams where development is done less formal, version control does a nice job at automatic merges, for example. Copying files around is tedious and error-prone, and it's IMO unlikely to share patches if you don't even use version control. No version control usually means strong code ownership - if so, if you dig deep enough, you'll find bugs which were fixed with delays because the code owner wasn't available. I'd expect you to find enough dirt when digging to be able to sell.
-
Hahahah! My dad does that! At every single opportunity that I have, I tell him about benefits of VCS, specifically GIT :cool:
Depending on the project at hand, IMO git is overrated. I like to keep everything under version control, including documentation. Git is notoriously difficult to use, and sometimes the effort isn't worth the benefits. Especially when working alone on a project, git does not make sense, IMO - git's benefit of cheaply managing branches are not really useful in that case.
-
you comment out your code instead of deleting it?! ;-)
Ohhh... Not sure on that one. If you modify that to say your production build contains commented code, then yes.
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
As I work alone, mostly, I don't use any particular program for version control, other than upon reaching a particular milestone I archive the code using WinRar and store on an external drive. Part of the problem, for me, is that learning and setting up a repository takes more time than I have to devote to it.
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
Their comeback will be very simply 'If it ain't broke don't fix it' and they might be right! VCS is not the ideal in every situation, it can make work harder and can be more error prone as people stop thinking! Worse they don't comment about changes in the code as 'oh we can let the version contol tell us' - wrong wrong wrong! You should also assume you can't trust your VCS and keep manual backups of all release builds or milestone releases. You will sleep easier and possibly keep your job longer! We use VCS but always use a manual backup for reverting to maintenance changes. We don't acualy fork so thats something we don't have to worry about (lucky us!)
-
Not a joke, but at my last company they did have production go down, and the backup was overwritten with the broken production, so the entire 500,000 lines of SQL stored procedures were lost. Or, they would have been if a coworker hadn't made a personal backup. Instead of fixing the situation (version control, off site backups, hardware that isn't ancient, employees that aren't tards, etc.), they put her in charge of backups. :doh:
I think I worked for that same boss at one point. :wtf:
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
I tried to do the same thing with a company that I worked for. When I asked one of the guys why he would manually copy directories for some revisions instead of using version control to create a revision history he replied (off topic even) that his code was proprietary because it was better than the rest, and that he didn't need to share any of it with the team, so version control was pointless. I asked him what happened if his house/computer was destroyed and he died. He said he hoped that maybe he could specify with his third party backup who could access the files. So... I guess: You might be a Version Control Avoider if.. you are arrogant and ignorant? I seriously could not believe that kind of response, it didn't even answer my question. It was like he just had that canned and somehow expected all of the people outside of his little bubble to just accept it as valid. I think he has since been forced to use a centralized repository to some degree.
-
As I work alone, mostly, I don't use any particular program for version control, other than upon reaching a particular milestone I archive the code using WinRar and store on an external drive. Part of the problem, for me, is that learning and setting up a repository takes more time than I have to devote to it.
MythicalMe wrote:
As I work alone, mostly, I don't use any particular program for version control, other than upon reaching a particular milestone I archive the code using WinRar and store on an external drive.
:omg: Version Control is not about achieving milestone. Milestones are just part of it. In version control systems milestones are know as "tags". You will also save a lot of disk space with that as you don't need to create entire project copies with version control systems. They just mark the differences that you can go back to easily. Version control is really about controlling what was where and when, even for a one person project. You can't possibly remember everything you done and version control is there to help. Sometimes you may break something that you realize only a long time after it was broken. You can see what and how something got broken by comparing the revisions of a particular file.
MythicalMe wrote:
Part of the problem, for me, is that learning and setting up a repository takes more time than I have to devote to it.
Take a look at TortoiseSVN[^]. It is really easy to setup a repository with it in two mouse clicks. You don't even need a server for it. You can setup the repository in local file system, external drive, or file share.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
kdmote wrote:
"You know you're a Version Control Avoider if..."
You have foldes like: \MyProject\Version 1.0 \MyProject\Version 1.1 \MyProject\Version 1.2 \MyProject\Version 1.3 \MyProject\Version 1.4 \MyProject\Version 1.5 \MyProject\Version 1.6 \MyProject\Version 1.7 \MyProject\Version 1.8 ....
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
I am in the process of trying to introduce Version/Revision Control to a team of developers who have never used it. I will be giving a presentation that I hope will be a persuasive explanation of the importance of Version Control -- the benefits of using it and the liabilities of avoiding it. I would like to kick it off with an amusing but instructive list modelled after the "redneck" line of jokes. Can anyone help me add to this list? -------------------------------------------------------------------------------- "You know you're a Version Control Avoider if..." • You have a bunch of files or folders with names like Engine_05212012_works_old[2].cpp • You've had to explain to your boss how you accidentally overwrote production code. -------------------------------------------------------------------------------- I don't consider myself terribly witty, but I think a little humor could be helpful in this situation. Any ideas for how to extend this list? [Bonus points if you can suggest a better moniker than "Version Control Avoider"]
I would re-phrase via self-deprecation to defuse... "I knew I was a Version Control Avoider when I ..." I think most people are amenable to version control as long as someone else goes through all of the pain and suffering of setting it up. If you can checkout, change, checkin and merge in a relatively painless fashion, then you should have no problem selling it. Merging is where they should see big paybacks! Here is one for your punchlines: "...when I had 10 personal copies of the website in various directories and various stages of repair and the only way I was sure which one was active was to check the web server config."