Do either of these situations sound familiar?
1) There’s one developer that’s been with the company for years. They’re not versatile or hardworking, but you can’t get rid of them, because they’re the only developer that knows some legacy system that’s critical for operations.
2) You have one primary developer that handles the majority of internal projects, but you’re worried about what will happen if this developer decides to leave the company. Nobody else knows much about the systems they’ve developed or is an expert in that coding language.
Most IT departments or software development teams have experienced something like this.
What follows are some best practices to avoid or correct this situation to ensure your team is never completely reliant on one developer.
1. Multiple people should know each project.
As a general rule, at least two people should be up-to-date on any platform you’re supporting. Turning this into a company policy can ensure people don’t feel singled out or threatened.
How to institute this rule:
- Focus on the practical: you want to make sure all systems are supported in case any one person is not available.
- You can also sell this as a way to spread out maintenance requests and make sure everyone is available to work on new (and interesting) development projects as they arise.
- Position this as a mentorship opportunity when you’re pairing up senior and junior developers.
2. Have a good knowledge transfer process in place.
Another extremely important company policy involves documentation and source control. If one of your developers isn’t using source control software and something happens, you can be in big trouble.
Unstoppable Software has worked with so many customers that need updates or fixes to a program that they have neither documentation nor source control for. The program is up and running with no backend support and they’re looking for us to somehow reverse engineer it.
Have policies in place around source control practices and documentation.
Source Control
Require daily or weekly updates (having source control doesn’t matter if the developer never uses it and the code hasn’t been checked in for six months.
Tools we recommend are Subversion, Github, and Beanstalk.
Documentation
We actually have a client that is paying us to go through each screen and document all the functionality of a legacy system (that we didn’t build). Without documentation, people don’t always know what a system can do, where it’s installed, and other necessary information.
Have a working example in place of how to write clear and detailed documentation.
There’s a debate around where documentation should be found — with extremists on either side thinking all or none of the documentation should be found in the code itself.
We personally think that code-first documentation can go a long way, but that some things don’t make sense to include there, such as server names and where the system is installed and deployed at.
We also believe that issue tracking is a part of good documentation — keeping solid notes on what went wrong, how it was fixed, and why you decided on a specific fix. Keeping your issue tracking in the same place as other documentation can make it easy to keep track of all of it.
Practical and detailed resources for how to write better code documentation:
- https://medium.com/@andrewgoldis/how-to-document-source-code-responsibly-2b2f303aa525
- https://blog.jooq.org/2013/02/26/the-golden-rules-of-code-documentation
How to Enforce These Practices
It’s easier to enforce good practices when you’re actively developing a program and the project is the priority of the department. You might have a project manager or senior developer who’s running daily or weekly meetings or managing sprints, etc.
But when a project is in the maintenance phase and there’s less active development happening, there’s often less oversight, as well.
Our best advice is to add check-ins about any of the above (source control, documentation, mentorship, etc) into your team or department meetings.
- Don’t want to call someone out? Make it a habit to check when a project was last checked into source control before your daily/weekly meetings.
- Add consistent one-on-ones to ask how mentorship/knowledge transfer/new tag-teaming efforts are going.
- Don’t always default to the lead developer when assigning tasks. Make sure anyone who is working on a project (even just serving as backup) is assigned the occasional issue to stay fresh on it.
- Have developers present their documentation to the team during group meetings.
As the supervisor or project manager, you have to turn this type of accountability into a habit for yourself in order for it to be a well-enforced practice throughout the team.
3. Have intellectual property clauses in your employment contracts
If your software is developed in-house and a part of how your company brings in revenue, it needs to be protected. Companies of all sizes run into issues around who owns their source code.
Source code can be considered intellectual property and protected by copyright laws. By default, a company owns the code created by an employer on the job. If you’re working with an independent contractor, by default they own what they create, although ownership gets way more nuanced in court.
With employee-created code, things can still get tricky around reusable code, fair use laws, or simply what an employee learns on the job. For two examples, check out Oracle’s lawsuit against Google or Calendar Research LLC’s lawsuit against Stubhub.
This is why it’s a good idea to have work-for-hire, non-compete, and non-disclosure agreements in your employee contracts and ownership clearly spelled out in contracts with independent contractors.
The same goes when outsourcing development. You should always check contracts to see who owns the finished product. It’s a part of our standard contract that anything we write for a customer belongs to them, and yet. we’re surprised by how few of our customers bring up this topic.
How We Can Help
At Unstoppable Software, we create long-term relationships with companies by offering a mix of services including custom software development, monthly maintenance contracts, and consulting services. Our goal is to support your teams by filling in the gaps of your in-house expertise and possible workloads. If a job is too complicated to develop in-house, we can help. If you’re looking to free up your developers’ time, we can help with mundane maintenance tasks, as well. Learn more about our three core services:
