The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.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"]
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.
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.
Thanks Mike, that is all excellent advice. Actually, I believe I have followed that strategy already and feel that I have a good understanding of the reasons for their reluctance. ("Our 'system' works good enough; why change it?" - even though it doesn't support diffing or branching or merging or coordinated collaboration.) It's not that they are resistant so much as they are unaware of the benefits of VCS. So my first goal is to help them see some of the drawbacks of their current mechanisms. (And not for my sake, but because I really believe it is going to help make THEIR lives easier.)
Nevertheless, your point is well-taken and I may need to reconsider my light-hearted approach in favor of a more direct presentation. But sometimes I feel that a little humor (if tactful and not derisive) can make the medicine taste better.
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.
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.
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 'system' works good enough; why change it? You: Tell me more, what does works mean? Them: Blah, blah, blah You: Interesting, tell me more? What does it do for you? Them: Blah, blah, blah You: OK, tell me about working with it... saving your work... merging your colleagues work into yours... comparing versions... etc. Them: Blah, blah, blah You: Tell me more. Them: Blah, blah, blah You: Oh, I think I get it, you mean that....? Them: That's it, it works for me, I use it, understand it, it doesn't get in my way, it's brilliant.
You now understand why they like it and what they get from it, why they think it's brilliant / good enough, etc.
You can now sell what VC does, directly adressing why it delivers all the same benefits they currently enjoy and why it makes those benefits easier / cheaper to achieve; they will buy in if they see that they get everything they have today with no losses and some personal efficency, ease of life benefits.
Nothing new, no bonuses, they haven't told you they want them so they won't listen. The bonuses come later, they have to realise them for themselves or you can begin to sell them only after the transition. Any benefit you sell that they haven't asked for dilutes your story. Ands 'asked for' in this context is nothing, they ain't asking, you're selling.
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).
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.
> "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!)
Just out of curiosity (forgive me if I missed a few details in the many posts here), is the introduction of Version Control supported by the stakeholder(s)?
In my experience, VC is the type of mechanism that can only be introduced if the stakeholders insist. Developers who don't already use it on their own must not actually be interested in it and probably won't be convinced by selling points presented from one of their own (assuming I understand your relationship to them).
I would think the sales pitch to the stakeholder should be pretty straightforward - as far as they're concerned it's the same need as buying insurance for any aspect of the business.
The mandate to introduce this MUST come from above. The questions of "Which VC platform?", "What branching model?" and "What best practices should we adopt?" are more of the issues that should be discussed among the development group (although still assuming some sort of management decision would be needed to make the outcome official).
Not that I need to sell my co-workers a VCS, but this post is utterly brilliant and I can see it coming in useful for me many times in future when I do need to sell an idea to those I expect to resist.
Thank you kindly, though I would point to the OP's comment (quite correct) that I made my point by ignoring it. I preached. It's good stuff (Andy's, it ain't mine) but what I did is not the way to do it
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.