Lock-in refers to a situation where prior decisions make it very difficult to change things later on. Lock-in exists in many areas, but it is in the technical sphere where it is often felt the hardest. A bad decision today can literally make life difficult for oneself – and many, many others – for a great many years.

The most extreme example I can think of is our calendar, where the way things are organized are based on mystical numerology from the time of the Babylonians (or maybe even earlier).

Think about it: why is the day divided into 24 hours of 60 minutes each? A metric system would greatly simplify any number of operations that need to divide time up into parts.

Modifying the way that we organize time, however, would involve replacing every clock in use around the world, and would have ramifications that simply can’t be predicted – think about all of the software that makes decisions based on specific times of day. Not just alarm clocks, but also scheduling software that involves large moving pieces of equipment. The last time a major calendrical change was made, back in the 16th century, it caused riots – and that was before modern automation technology (and things like futures contracts).

Last year I built a relatively high-traffic e-commerce website, and designed the underlying data structure for invoicing in a specific way (based on the functional specs, mind you) – and it turns out that the users of the site actually would prefer to do things somewhat differently. Fixing the problem now means performing surgery on a piece of software that runs 24-7 (yes, we have various test sites), and potentially migrating hundreds of thousands of invoices to a new (and likely incompatible) data format.

Another personal example is a quick and dirty reporting tool that I built back in the dot.com era for an insurance company. The tool was designed for a single user, and was built using Microsoft Access 2000 (and later ported to 2003). This made sense because it was never intended as anything more than a set of simple reports for one specific manager.

Of course once the tool was done, several other managers asked for access to it in order to put in reports of their own, resulting in a small modification to make the tool more compatible with multiple users, and a few more reports.

Nearly a decade later, the tool is still in use, is still growing in scope, and has now made it difficult (maybe impossible) for the entire company to upgrade their application software. Replacing the tool at this point would imply a complete redevelopment from the ground up, including replacing a big chunk of their infrastructure.

The moral of the story is simple (but sometimes hard to put into practice – as illustrated above): when building something, be aware that the decisions you make can and will have follow-on effects down the road – and try to make sure that you understand what those effects will be.