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
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.