You just joined a small team of developers. You are asking a bunch of questions about the code base. What technologies are we using? How do I set up my development environment? Where is the code? Someone on the team then presents you with a zip file. The terrifying reality washes over you. Your team isn’t using source control. The developers are writing and compiling code on their local machines. The developers are deploying to the test environments manually. It’s the wild wild west.
You know that it is up to you to lead your team into the light. You also know that developers can be incredibly resistant to change. They have been working this way for however long, and they shoot down all persuasive arguments to change. Even if you can get them to logically agree with your position, you likely won’t be able to change their day to day habits with mere words. You will somehow need to make them live in the new world and see the benefits.
Leverage the power of automating deployments. If your team isn’t using source control, it is very likely that they also have an annoying and tedious deployment process. This manual deployment process is likely causing extra work for the development team and whatever operations staff is in charge of releasing code changes to production. If you can put together a simple automated build and deploy process that pulls changes from source control, you can sell the convenience of that process to your operations staff. You should be able to even convince them to refuse to deploy any other way. Once you do that, the trap is set! If setting up an automated build and deployment for all of your code is too daunting, try and find a smaller section of the code to break off and automate. You don’t need to do everything at once. You just need to start the fire somewhere.
Educate your team on how to use the tools. Lead team workshops where you demonstrate the basic functions of your chosen source control tools. If you are using git, I would recommend sticking with the command line interface for the basic commands. Find a simple visual tool like TortoiseGit for more complicated things like conflict resolution after a merge. Document how to view and modify the automated build process if your code requires compilation. Document how the automated deploy scripts work and where they live. You will want to walk your team though these processes as well, but they likely won’t learn everything on the first pass. You will need to provide them a series of clear reference materials to ease their transition.
Be patient and be disciplined, because people are stubborn. It might take them a while to truly understand and believe in the new process. As long as you have the support of the operations staff and management, forcing the team to use source control will eventually convince them of the benefits. At some point along the way, they will have a moment (or twelve) where the new process saves them a ton of hassle. Unless your team is unimaginably dense, the light bulb will eventually come on.