Almost anyone who has worked in IT has come across a scenario where a single developer basically controls the entire system. Whether it was by choice or necessity, this can create a challenging scenario for management. The developer, while a valuable asset, can become a bottleneck (the part of the system that allows the least work to flow through). When this occurs, we have to balance the need to keep the employee happy with the need to accelerate our processes.

What should you do?

This situation happens more than people think. It’s frustrating and a challenging decision, but there are several things you can do to correct this scenario and make sure it never happens again, including:

  1. Share knowledge between the other people who need to access the system and the person who controls the changes.
  2. Develop a parallel way to control the system and implement changes where there is not a single person controlling the ability to change.
  3. Make sure it doesn’t happen again.

Share Knowledge

This part is going to be the most challenging. The developer that created the system is basically a lone wolf. He is used to working by himself. The software is his baby. He knows everything about it, but didn’t bother to document it cause he knows it like the back of his hand.

During this process you need to reaffirm his value to the organisation, but help him understand that his value grows if he removes the moat he has built for job security and focuses on being a leader to help the rest of the development team gain access and understanding of how the software is currently structured and coded.

If you can get the developer to work with other parts of the team to develop the necessary documentation and access to help the system grow to be more effective, you can make the other steps easier. Cooperation could lead to a point where he can guide the process as opposed to control it, turning him into more of a supervisor. If the resistance to change is too great, then other alternatives may be necessary.

Reverse Engineer the Software

Because many software developers feel threatened when they have to give up control, you may have to reverse engineer the software to figure out what the dev did, why, and how to connect to it. The good news is all code is in English so reading the program is a matter of time. The first step in reverse engineering the software is setting up a test environment and working with the code to debug it. In the process, the development team will learn the functionality.

Once the team has developed familiarity with the software, you can now implement the changes or additions needed to the software. Hopefully by the time you have reached this point, the original developer has realised that cooperation is in the best interest of all parties and starts being fully cooperative.

Make Sure It Doesn’t Happen Again

The final step in correcting a sole developer dependency is making sure it never happens again. Having policies in place such as requiring documentation before a project is verified as complete, having developers work in teams, or utilising an external software development team are all effective ways of preventing sole developer dependencies.

For those who are just starting an organisation and only have the budget for a single developer, I would recommend looking into hiring an external team. Many businesses start with a single developer and grow the team from there, but doing so can easily create a sole developer dependency over time. This mistake can be easily avoided by hiring a team like Flying Donkey IT. Using the same budget that you would spend on one developer, you will have access to typically three developers working together to make sure your software never develops a sole developer dependency. To learn more about our services, go to our Team Augmentation Page. If you have any questions, please reach out.

Cheers!

Mathew Grace