If the opportunity arises, try the following approach: Tell your client " I use some very specific tools for my work as they increase my productivity and efficiency, and as part of the work i deliver to you, i'd like to continue using those tools to deliver to you. You'll receive multiple benefits as a result, and i can name them if you wish, but don't wish to bore you with technical details"
Just try it. Not making any promises, but i think you'll have better luck if you do.
Sounds like you're either framing things wrong, or allowing certain people to make the decision when it should be yours to make ;-)
I suppose it depends on if you're trying persuade another programmer or the end customer.
The way it is framed seems to suggest that they have an existing (probably solo) developer who is used to not using version control and is frightened by the thought of adding new tools and processes.
If you introduce such a person to version control it will necessitate them spending some time to learn the system which they may be defensive about since they see it as some outsider encroaching on their territory.
In such a case the best bet might be to follow their method until you hit some situation where there is a problem or significant reduction in productivity as a result (shouldn't take long) and then demonstrate the virtues of using source control.
If on the other hand it is a non technical person who is making specific dictates about source control then that might raise another set of red flags.
Yeah - When I was providing IT support services, we used to run into a similar kind of problem all the time. In the end we realised that we were going to execute in a way where they had no option but to use the tools that we wanted. We at all cost avoided getting into a debate with internal IT staff, and as for the client gave them only one option which was to do things the way that we wanted.
Your method of using appropriate timing to introduce new tools is also what we employed and works very well.
Comments
If the opportunity arises, try the following approach: Tell your client " I use some very specific tools for my work as they increase my productivity and efficiency, and as part of the work i deliver to you, i'd like to continue using those tools to deliver to you. You'll receive multiple benefits as a result, and i can name them if you wish, but don't wish to bore you with technical details"
Just try it. Not making any promises, but i think you'll have better luck if you do. Sounds like you're either framing things wrong, or allowing certain people to make the decision when it should be yours to make ;-)
I suppose it depends on if you're trying persuade another programmer or the end customer.
The way it is framed seems to suggest that they have an existing (probably solo) developer who is used to not using version control and is frightened by the thought of adding new tools and processes.
If you introduce such a person to version control it will necessitate them spending some time to learn the system which they may be defensive about since they see it as some outsider encroaching on their territory.
In such a case the best bet might be to follow their method until you hit some situation where there is a problem or significant reduction in productivity as a result (shouldn't take long) and then demonstrate the virtues of using source control.
If on the other hand it is a non technical person who is making specific dictates about source control then that might raise another set of red flags.
Yeah - When I was providing IT support services, we used to run into a similar kind of problem all the time. In the end we realised that we were going to execute in a way where they had no option but to use the tools that we wanted. We at all cost avoided getting into a debate with internal IT staff, and as for the client gave them only one option which was to do things the way that we wanted.
Your method of using appropriate timing to introduce new tools is also what we employed and works very well.