How to Minimize Vendor Lock-In as a Reluctant Product Manager

What does vendor lock-in look like?

Vendor lock-in is a big issue in software development, and all too often, it is an insiduous process. As a reluctant product manager, you might not be aware of the risk until a key developer or the whole team leaves, and you learn the hard way that essential knowledge about the system is lost.

At that point, you might find that the development team seems hesitant or even incapable of making changes. And even when they do, you might be confronted with bugs, as the development team doesn’t have a full understanding of the system.

What causes vendor lock-in?

The most common causes for this situation are:

• The system might have become too specialist, large and complex for new developers to fully understand it. They lack the benefit that the original developers had of getting to know all workflows organically during the development process.
• The source code might be of poor quality, so that it is hard to read by anyone but the developers who wrote it. Often, made worse by lack of documentation and functional tests.
• The technology stack might have gone out of fashion, so you can no longer find good developers to work on the source code.

How can vendor lock-in be prevented?

If you’re at the beginning of a development project, you are in a great position to put the right measures in place:

1. Above all, ensure that at least the main workflows are documented and covered by functional tests. Ideally, you’ll want an executable specification, following the Specification by Example paradigm. This is a collaborative task for a business analyst and a senior developer.
2. Have an independent QA person review all source code during the development process to see if it is well-organised and clearly written.
3. Ask an independent software architect or senior developer to do a risk assessment on the choice of technology stack, so that you have a better understanding of the chances of it going out of date at some point.
4. Make sure that technical knowledge is spread across teams and documented. For example by having an in-house software architect or developer work alongside an external development team.

How can vendor lock-in be mitigated later on?

The good news is that in most cases, you’ll still be able to get unstuck at a later stage. The bad news is that it will cost more money and take more time.

In any case, the first thing you need to do is getting an executable specification in place (again, Specification by Example is the preferred method here).

This is a tedious task, as you basically need to reverse-engineer the requirements of an application that has already been built — so it will feel like putting the cart before the horse. It is a necessary task however: tests will be your only way out of this predicament.

Once the tests are in place, you are in a much better situation, and you can:

• either, have the source code refactored, which means improving the readability and organisation of the source code without changing the functionality,
• or, have the source code partially or fully rewritten, based on the executable specification, either in the same technology stack or another.

Conclusion

As a product manager, you need to be aware of the risk of vendor lock-in, which is getting stuck with development and maintenance at a possibly very unfortunate time.

As is the case with so many problems, the cost of vendor lock-in goes up for every day that it is ignored!