Easter's Laws of Concurrency

I've been reading Brian Goetz' Java Concurrency in Practice. It has some mind-expanding thoughts on how subtle it can be to have threading problems in Java (or any language).

The book, and Amdahl's Law, has inspired me to codify a warning to junior developers (apprentices, in the parlance of Code to Joy), and as a reminder to the senior devs (composers).

Preface

A program is said to be thread-effective if it is:

• (a) thread-safe
• (b) efficient with respect to concurrency (e.g. throughput, UI responsiveness, etc)

Define a program's probability of thread-effectiveness (PTE) to be a metric ranging from 0 to 1, where 1 is complete certainty of thread-effectiveness.

Easter's 1st Law of Concurrency

If you don't know if your program is thread-effective, then its PTE is approximately 0.

Easter's 2nd Law of Concurrency

If you think that your program is thread-effective, then its PTE follows the specified equation:


where:

• C is a random constant between 0.01 and 0.025
• E is experience

Experience is difficult to define in practice, but an approximation is:






where:

• P is the number of programs successfully debugged with respect to thread-effectiveness
• B is the number of books read (in their entirety) on thread-effectiveness

Easter's 3rd Law of Concurrency

If a progam's thread-effectiveness is not optimal, problems will eventually manifest themselves. This manifestation will follow neither Murphy's Law nor the related Law of Demos.

Instead, the problems will manifest themselves, in production, long after you have moved onto other issues and have forgotten the intricacies of the design. This will leave you to rely on the quality of design and documentation as the primary means of fixing the problem.