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).
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)
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:
- C is a random constant between 0.01 and 0.025
- E is experience
- 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
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.