Imagine you encounter a random production service. Knowing information beyond how long this service has been in production, how long should you expect that production service to last into the future, given only how long that service has been in production? The Lindy effect suggests that the expected lifespan of a random production service is proportional to its current lifespan. If a service has been in production for ten years, we might expect (a priori) for that service’s expected remaining lifespan to be ten years.

Corollaries

Although there may be reasons to doubt that this thesis applies to production services (perhaps we can attempt to explore them at a later time), if we accept the premise that lifespan of a service is proportional to its current lifespan, there’s a few interesting corollaries.

Retiring Legacy Services

What are the hardest legacy services to retire? Well, the Lindy effect would suggest that the oldest services are the most difficult to retire. When one goes about retiring a particularly old service, one should temper one’s ambitions that it will be particularly easy.

Similarly, imagine you have multiple services with overlapping functions and you wish to consolidate these services into a single service. Which service should you expect to take the longest? My experience is that the oldest “redundant” service is the hardest to retire. I suspect that this cannot be explained by the Lindy effect, but is another interesting “age” effect (this might be worth exploring at a later time).

Relying on Outside Services

Why are companies often hesistant to become dependent on new outside services? If the expected lifespan of an outside service is proportional to its current lifespan, brand new services seem particularly risky. Non-trivial software projects typically take at least a year, and particularly new services might become defunct by that time.

Something important to note is that the remaining lifespan of that service (once again, knowing nothing else) is proportional to its current lifetime. If you adopt a service which is two years old, perhaps it’s expected remaining lifespan is two years. If, after a year, that service is still around, you should expect its remaining lifespan to be three not two years. This is because, once again, the expected lifespan of the service is proportional to its current lifespan.

Libraries

Someone at your workplace might have heard about “hot new framework X” and is eager to integrate that to production. How often is that a good idea? Well, the answer is likely closed related to “how long has the framework been around?”. The shorter the frameworks lifespan, the more skeptical one should be that it will be around for long. This may be fine in certain contexts (start-ups, one-offs) but undesirable in other contexts (production systems).

An interesting example of the above is, given NodeJS’s relatively meagre standard library and it’s relatively great package manager, early NodeJS projects seem to have been forced to use relatively immature libraries. Many of these libraries were abandoned (for any number of reasons), burdening developers with migrating to newer libraries. This is much less of an issue today, largely because NodeJS is itself now relatively old.

An interesting question is whether one can judge the maturity of a given “application area” by the age of it’s libraries. it seems (to me) that as the web development ecosystem has matured, the number of “hot new frameworks” has declined and that the average age of the top K frameworks (where K is small, at most 5) has increased substantially. Once the average age passes a critical threshold, it becomes unlikely that any of these frameworks will be displaced and the field has effectively matured.

Project Overruns

You’re working on adding a new feature to “some application”. Everyone thought the feature would take X weeks. It has taken X weeks, and it’s not done. How much longer should you expect it to take? Well (as you probably predicted), a not terrible guess (without trying to incorporate other information), is that the project’s expected remaining duration is X weeks. If you were feeling pessimistic about a failing project, this should make you feel more pessimistic about its prospects.