The first thing I do when starting a new project is get everyone on git. If the project is far along and is using svn, I can live with that ... sort of.
The next thing I do is explain that I will be spending more time for coding upfront because I will introduce testing into the project.
I'd be interested to know how you sell git to your clients.
I have listed all the positive benefits of version control in detail to my clients and still have the idea rejected due to it being an "unnecessary complication"...
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.
Clients don't really care what tools I use. I just tell them what I'm going to need to provide the guarantees we both signed in the contract.
Other developers can be trickier, but it's very simple to get logical people on the path of version control if you override their changes once or twice. (usually unintentionally)
Actually, the only time I've encountered zero version control, I simply refused to start working until git was introduced into the project.
They usually want me to fix old code ... exploratory tests are really the only way to do that.
It helps that I write integration/functional tests almost exclusively (unit tests are imho useful only for algorithms, which is not what I'm usually working on).
I mean, I can either spend 20min writing a test, or 5min clicking around the app every time I change something ...
Comments
The first thing I do when starting a new project is get everyone on git. If the project is far along and is using svn, I can live with that ... sort of.
The next thing I do is explain that I will be spending more time for coding upfront because I will introduce testing into the project.
These are not negotiable.
I'd be interested to know how you sell git to your clients.
I have listed all the positive benefits of version control in detail to my clients and still have the idea rejected due to it being an "unnecessary complication"...
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.
Clients don't really care what tools I use. I just tell them what I'm going to need to provide the guarantees we both signed in the contract.
Other developers can be trickier, but it's very simple to get logical people on the path of version control if you override their changes once or twice. (usually unintentionally)
Actually, the only time I've encountered zero version control, I simply refused to start working until git was introduced into the project.
Do you retrofit tests to old code? If so how do you deal with spaghetti that at first glance appears almost untestable, insist on a refactor?
They usually want me to fix old code ... exploratory tests are really the only way to do that.
It helps that I write integration/functional tests almost exclusively (unit tests are imho useful only for algorithms, which is not what I'm usually working on).
I mean, I can either spend 20min writing a test, or 5min clicking around the app every time I change something ...