About the dev lock-in

Nowadays, most (smart) companies know that they should avoid vendor lock-in.

However I still see a lot of companies allowing dev lock-in to settle in although it is almost as bad as vendor lock-in.

What is dev lock-in ?

According to Wikipedia, "vendor lock-in [...] makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."
Well, dev lock-in is the same for developers: it makes a company dependent on a single person (the developer) for projects and actions, unable to ask another developer to do it without substantial switching costs.

There are multiple situations that can be considered a dev lock-in, but the most standard one is "Hey, please meet Steve. Steve was the only developer assigned to this critical project. Steve has written the codebase following his own standards, his own logic (that most people don't understand), has never written any documentation nor automated tests and is the only one who knows how to deploy."

Most of the times, you can add "funny" parts to the story:

• 50% of the deployments fail and result in a downtime, there is no back-up or rollback possible, Steve does this manually on the server
• The code ? Oh, it's on the server and on Steve computer. What ? Versioning tool ? Git ? What are these alien words ?
• How do we work on a daily basis ? Well, we tell Steve what we want to do and he says "OK, done", then we check on the production if it works well. What ? "Staging server" ? Never heard of that, no.

But the saddest part of the story is that very often, Steve is not a bad person and is not aware of the lock-in he created. Steve has just been given a project too important for him so he did what he could all by himself. You guessed it: usually, Steve is actually a junior developer and there was no senior developer with him to help him build things right. And now the company has a dev lock-in plus a huge technical debt.

But dev lock-in can happen in a company for a lot of reasons:

• in a team, everybody leaves except one (a junior dev) and there's so much work suddenly that the dev "left behind" cannot do things properly so he locks-in the project unintentionally
• the company hires a "10x ninja magicien developer" that is actually a pyromaniac dev who says that "testing is for the weak" or "move fast, break (every)thing(s) !"
• ...

What should your company do to avoid dev lock-in

Dev lock-in is mainly happening because there is a lack of communication. How does the codebase works, how does it get deployed, how do you modify this thing, how do you store it.
So obviously the very 1st tool to fight dev lock-in is communication. And if you are a developer, communication means documentation.

Write documentation for newcomers. Write documentation for advanced users. Write documentation for the deployment process. Write documentation about previous incidents. Write tutorials and examples. Draw schemas, they are great communication tools !
And share it. And make sure it is updated on a regular basis.

Secondly, have a team with more than one member in it, and make them switch projects. Do not keep a person on a project "because he knows it better, so he'll do it faster if we assign this task to him". That's the trap.
Even if you think that your developer or co-worker is a trustable guy and that, if one day he decides to leave, he will perform a correct knowledge transfer, please remember that people can get ill ... or die. Yes, you heard me correct. There was one company who had a dev lock-in with one dev but was sure the guy would never leave because he was so happy there. The guy died in a car accident. The day after his death, nobody knew how to deploy. So please never rely on a single person. Always have multiple team members know about the critical parts of the system.

The 3rd tool you can use to fight dev lock-in is to use standards. Don't reinvent the wheel. If you can use something that is widely used by other devs, do it. This will make it a lot easier to onboard these people on the project if you need to: use standard frameworks, use popular tools, use popular ORMs and libraries and specifications. Follow popular codestyles and naming conventions. The more standard your codebase is, the easier it will be to have another developer to get onboarded on the project if you need him to.

This applies to technology choices too. Let's say that you have to choose between technologies X and Y for your latest project.

Technology X can give you a boost of performance of 0,01%, compared to technology Y. But Y is a trending technology with a team of 12 maintainers on github and everybody around is starting to use/implement it while X is maintained by a single guy and the last release was 2 years ago ...
Here, you better choose Y and lose this 0.01% of performance but enjoy the reliability and safety of a standard technology.

Dev lock-in can also happen when nobody wants to take over the project because it's too old, has too much technical debt, or uses technologies nobody knows/uses/loves. Yep, that's sad, but trends do matter. Your codebase or your project needs to be able to attract and motivate the people who work on it. Else, you'll get locked-in the existing team that will one day leave.

Lastly

I hope this article was interesting for you and will help you make the right decisions to avoid dev lock-in in your company. Be careful, because sometimes ... you are the lock. Yes, if you are alone on the project, consider asking your manager to hire someone else so you dont lock-in the company you work for :) .