Sometimes the best way to convince someone that their way will not work is letting them fail early without any major impacts.In my first job in the early 90s, Microsoft shipped a version control called Delta with MSDN. It was not really good and did not have any Developer tool integration but it supported basic version control features like Check In and Check Out and it was free with MSDN, so I did not have to go through an approval process to get it.
Delta provided some basic features and I and my team was happy using it compared to the previous option of using nothing.
One of the developers in my team was very unhappy that he had to ‘Check Out’ a file before using it – This meant that he had to switch to Delta from his C++ editor and check out and come back again. So he decided to just change the read only attributes of the file and continue working. He explained to me that since he was the only person who owned that file, it would not matter.
This was an accident waiting to happen. Even if you are the only developer, you will want to pull up an older version to compare the changes to figure out why – what you did today broke something else.
Sure enough a week later, he came to me one evening and told me that he messed up and wanted to go back to an earlier revision of the file but since he was not using Delta, he ended up wasting the entire day trying to backtrack his changes. Sheepishly, he admitted that he had learnt his lesson the hard way and would always use a version control system.
I suppose I could have taken a heavy handed approach and told him that the policy was to use version control or else but that would not solve anything. I still do this and it confuses the folks sometimes but it works.
Letting people fail in a controlled environment is the best way to learn – if they are not willing to listen. After all that’s how most folks learnt to ride a bike.