How to Avoid Lock In

As a business person faced with the task of hiring and overseeing the work of a design or development firm it can be extremely difficult to know if you are hiring the right people. Sometimes you will have a sense about the people you are considering hiring, but often you lack the technical skills required to make an informed hiring decision. Even worse, unscrupulous developers can build systems that other developers will not be able to decipher, leaving you dependent on the original developer for the life of the system. This means that your bad hiring decision can haunt you for decades. Being trapped into using a particular system is known as “Lock In” and it is preventable.

What is Lock In

Lock in can take many forms, we will try to cover the most common forms and how you can avoid them. Lock in can occur when:

  • Data is stored in a proprietary format
  • Code is so poorly documented that other developers cannot decipher it
  • The developer retains sole rights to the code they write for you

Proprietary Data Formats

There are many ways to store data electronically. Programs are made to read and write data in a particular format (just as people read and write in a particular langauge). Programmers can use exisiting formats or create their own. Existing formats are either closed, proprietary formats or open formats. Closed formats are controlled by the created and are generally kept a secret so that only the software provided by the format creator can read or write files in this format. Open formats are public knowledge and anyonne can create software to read or write in that format.

Storing data in an open format frees your data from the software that was developed for you. If you find that the software is lousy and decide build or buy a new system, having your data in an open format will make the change easier.

Take Action: Talk to your developer about how your data will be stored and how it can be exported to another system when and if you choose.

Poorly Documented Code

Some developers don’t document their code in order to make themselves indispensible. If nobody else can understand what they built they can never be fired. This is often done by developers who lack confidence in themselves. It is a misguided attempt to ensure job security in a field that is constantly changing. It also results in you having a very poorly documented system that may be impossible to fix or update if anything ever happens to the original developer.

Take Action: Ask your developer to create documentation for their code, explaining what everything does. Ask them to go over the documentation with another, independent developer who can serve as a backup if needed.

Rights to Code

A poorly written contract can also lead to lock in. A fair contract will give both the developer and your organization rights to the code you paid for. You should have full rights to use and alter the code in any way you see fit. The developer should have full rights to use and alter the code in any way they see fit. This arrangement will allow developers to leverage their work in future projects. You will have the freedom to use the code forever whether or not you continue to have a relationship with the original developer.

Take Action: Make sure your contract grants both parties full rights to use and alter the code in any way they choose in perpetuity.

Lock in is a complex issue and as a business person it is a real concern that you may be ill equipped to face. Talk frankly with any developers you are thinking of doing business with and of you are still not sure you can hire a second developer as an auditor with the understanding that they are there only to protect your interests in dealing with the first developer. You can contact Infinite Web Design with questions about lock in or if you are interested in education on how to work with developers.

Kevin Hall
Latest posts by Kevin Hall (see all)