A lot has been written about why software developers leave, and how you can avoid it. But you can never avoid it entirely. So you must have a way of reducing the damage you experience when someone leaves.
You Can’t Keep People
My father worked for Philips for 20+ years. Most of my friends and colleagues haven’t worked at the same place for more than 10, maybe even 5 years.
The current economy demands flexibility from employees. But it goes both ways. Employees have come to expect flexibility from employers: remote work, flexible hours, and also regular changes in their career path.
What does this mean for you as a manager or company owner?
People will leave, regardless of how attractive your company is. Even when they enjoy working for you and seemingly have no reason to leave, they still will. And it’s not easy to predict when they will hand in their resignation.
This rings especially true for the software development industry, where demand for developers is high, but supply is low. This trend is increased because more and more developers are becoming “consultants” and move from project to project.
Consequences of Developers Leaving
Depending on the level of skill and experience of the leaving developer, your business will experience several problems. The consequences of someone leaving can be many, but I’ll focus on the software development aspect here.
First, your business loses some knowledge about the business problem that your software solves. This means that requirements won’t always be as clear as they used to be, certain good questions won’t be asked until later in the process, and good solutions might be missed.
Second, knowledge about the software and the code is lost. Each application has pieces of code that are weird or hard to understand. Maybe there are pieces of code that only that developer has seen and understands. If this developer leaves, the other developers’ productivity will decrease for some time. In fact, having a developer leave, could immediately increase your level of technical debt.
So what can we do about this?
What to Do
There are several ways of reducing the damage your organisation might feel when a developer leaves.
Documentation
A first reaction of managers is often to ask developers to document the software as much as possible. The reasoning is that new developers can read the documentation and then get started smoothly.
This is only partly true. If you document too much, you risk overwhelming the newcomer. You will also almost certainly end up with documentation that is hard to navigate and out of date with the current code.
But you do want a certain level of documentation. This is useful for all developers, both new and old.
So how much is enough? Good examples to look up to are the many open source libraries that have documented their usage. Another way is to start small and expand as people ask questions to the seasoned developers. Instead of just answering, have them update the documentation.
Quality Code
It is important to allow the team to write quality code, not just crank out features as fast as possible. Code that is well written and well structured is easier to work with as a newcomer.
Martin Fowler has written about how quality code is cheaper, and calls it the Tradable Quality Hypothesis. He correctly points out that quality code is cheaper because it allows developers to implement new features faster.
But quality code also allows new developers to get up and running faster. This is another way in which quality code means less money wasted.
So make sure your team is using well-known patterns, writing clean code, and writing automated tests. If you’re not sure about this, have an outsider review the code and make recommendations.
Focus on Your Core Business
You most likely have a piece of software that caters to your core business. This is the software that you’re selling. But it’s likely that you have other software running in your business. Examples are:
- services to integrate two applications (e.g. messaging systems)
- software for the daily operation of your company (e.g. time-tracking software)
- components used by other applications so certain behavior is the same across the company (e.g. logging libraries)
These pieces of software take more time and money than you think. Not only do they have to be written, they also have to be maintained. Even though there are usually great free or paying alternatives that work better for a fraction of the cost.
It also means that when the maintainers of this custom software leaves, nobody really know how the internals work.
And as a last point: newcomers won’t be familiar with the software. Your company is also the only place where they can learn about this software. On the other hand, most open source or commercial products have vast amounts of documentation and support available online.
So remove the cruft that is costing you more than necessary and replace it with the great options that are out there.
Losing Developers Doesn’t Have to Be a Disaster
People come and go. That’s as true for the software development as it is anywhere. And while this presents a challenge for you organisation, there are ways to reduce the potential damages. If you have good documentation, quality code and only your most important software to support, then losing developers isn’t all too bad.