Image created with Midjourney. Image prompt: 2d illustration minimal style of an abstract network with nodes and connections, each node falsely represented with glowing reliability, zero latency, infinite bandwidth, unbroken security, static topology, single administration, no transport cost, and homogeneity. The nodes gradually morph into their true forms, revealing the stark reality of distributed computing

Image created with Midjourney. Image prompt: 2d illustration minimal style of an abstract network with nodes and connections, each node falsely represented with glowing reliability, zero latency, infinite bandwidth, unbroken security, static topology, single administration, no transport cost, and homogeneity. The nodes gradually morph into their true forms, revealing the stark reality of distributed computing

Creating software that operates seamlessly in a distributed computing environment is a complex endeavor. The task becomes even more challenging when developers fall into the trap of believing the "Fallacies of Distributed Computing." These fallacies are a set of assumptions about networked computing that, while seemingly reasonable, can lead to significant failures in software development1. Let's delve into these fallacies through three real-world examples and discuss how understanding them can improve the process of creating digital software products.

Also known as Fallacies of Networked Computing, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:

The first four items were listed by Bill Joy and Tom Lyon around 1991 and first classified by James Gosling as the "Fallacies of Networked Computing". L. Peter Deutsch added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.

The group was inspired by what was happening at the time inside Sun Microsystems.

These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.

Examples

The Network is Reliable

One of the most common fallacies is assuming that the network is always reliable. In reality, networks can and do fail, leading to lost or delayed data transmission. An example of this is the failure of a messaging app due to network issues. If the app is designed assuming constant network reliability, it might not have proper error handling for network failures, leading to lost messages or app crashes. By acknowledging that networks can be unreliable, developers can build software with robust error handling and retry mechanisms, resulting in more reliable and user-friendly applications.