Refactoring reliability, scarcity, dependency

docs/practices/Communication-And-Collaboration/Training.md

@@ -22,7 +22,7 @@ practice:
   attendant:
    - tag: Schedule Risk
      reason: "Training sessions can take time away from development, impacting schedules."
-   - tag: Dependency Risk
+   - tag: Reliability Risk
      reason: "Creates a dependency on training programs and their effectiveness."
   related:
    - ../Documentation

docs/practices/Deployment-And-Operations/Configuration-Management.md

@@ -22,7 +22,7 @@ practice:
    - tag: Complexity Risk
      reason: "Reduces complexity by managing system changes in a controlled and documented manner."
   attendant:
-   - tag: Dependency Risk
+   - tag: Reliability Risk
      reason: "Dependencies on the CM tools and processes can become critical points of failure."
    - tag: Security Risk
      reason: "Incorrect configuration management can lead to security vulnerabilities."

docs/practices/Deployment-And-Operations/Demand-Management.md

@@ -15,7 +15,7 @@ practice:
    - "Capacity Planning"
    - "Resource Scaling"
   mitigates:
-   - tag: Scarcity Risk
+   - tag: Reliability Risk
      reason: "Helps in efficiently allocating resources to meet the demand without overburdening the team."
    - tag: Deadline Risk
      reason: "Ensures that the demand is managed to meet delivery schedules."

docs/practices/Development-And-Coding/Debugging.md

@@ -22,7 +22,7 @@ practice:
   attendant:
    - tag: Schedule Risk
      reason: "Debugging can be time-consuming, affecting project timelines."
-   - tag: Dependency Risk
+   - tag: Reliability Risk
      reason: "Debugging may reveal dependencies on other systems or components."
   related:
    - ../Development-and-Coding/Coding

docs/practices/Planning-And-Management/Prioritising.md

@@ -25,7 +25,7 @@ practice:
    - tag: Deadline Risk
      reason: "In order to hit a deadline, you can de-prioritise less important work."
   attendant:
-   - tag: Scarcity Risk
+   - tag: Reliability Risk
      reason: "Prioritization can create dependencies on specific tasks or features."
    - tag: Market Risk
      reason: "Prioritising a single client or narrowing scope reduces diversification, increasing exposure to changes in the market." 

docs/practices/Planning-And-Management/Requirements-Capture.md

@@ -22,7 +22,7 @@ practice:
   attendant:
    - tag: Feature Drift Risk
      reason: "Requirements will evolve and this can lead to feature drift."
-   - tag: Dependency Risk
+   - tag: Schedule Risk
      reason: "Thorough requirements capture can be time-consuming."
   related:
    - ../Planning-and-Management/Prioritising

docs/risks/Coordination-Risk/Coordination-Risk.md

@@ -93,9 +93,19 @@ Refers to a situation where, in an environment where multiple parallel processes
 
 ### 7. Scaling
 
-[Amdahl's law](https://en.wikipedia.org/wiki/Amdahl's_law) and [Gunther's Universal Scalability Law](https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Scalability_Law) both draw attention to the fact that as you increase the number of agents that need to coordinate, the more time needs to be spent on coordination.  These laws were originally drawn from observations on computer hardware, but they apply generally to problems of coordination.  While Amdahl's Law shows the diminishing returns of adding extra agents, Gunther's Law goes further to model how performance can get worse with extra agents involved - something we see when our computers thrash or when roads get really busy.
+[Amdahl's law](https://en.wikipedia.org/wiki/Amdahl's_law) and [Gunther's Universal Scalability Law](https://en.wikipedia.org/wiki/Neil_J._Gunther#Universal_Scalability_Law) both draw attention to the fact that as you increase the number of agents that need to coordinate, the more time needs to be spent on coordination.  These laws were originally drawn from observations on computer hardware, but they apply generally to problems of coordination.  While Amdahl's Law shows the diminishing returns of adding extra agents, Gunther's Law goes further to model how performance can get worse with extra agents involved - something we see when our computers thrash or when roads get really busy.  This also explains [Brooks Law](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) - "_Adding manpower to a late software project makes it later._"
 
 **Threat**: The more agents involved in coordinating, the harder and more time consuming it becomes.  
 
+:::tip Anecdote Corner
 
+Coordination Risk generally focuses on the problems inherent in _trying to get more coordination_.  But at the other end of the spectrum, crypto-currency systems like Bitcoin are predicated on the idea that the participants of the system are _not coordinating_ but are competing - and this keeps the currency running.  
+
+However, if participants coordinated, they could perform what is known as a [51% Attack](https://www.investopedia.com/terms/1/51-attack.asp) - effectively taking control of the currency via a majority share of the activity. This happened in 2019 when two mining conglomerates banded together to reorganise the blockchain and change the transaction history of Bitcoin Cash, a fork of Bitcoin.  Although this could have been done for nefarious purposes, they actually coordinated in order to fix some erroneous transaction state for the good of the network.  
+
+This was in their interests as fixing these issues increased the value and trust of Bitcoin Cash and therefore the value of the holdings of the mining conglomerates too. But it could have easily gone the other way, with a nefarious party stealing from the network.  That is didn't happen is down to the economic incentives of the miners involved:  they don't want to damage the reputation and therefore the value of the currency that they are mining.  
+
+The fact that mining consortia needed to band together to fix issues in the network demonstrates a central issue with a distributed system like Bitcoin:  as the protocol is designed on the basis of competition, change is very hard to coordinate and effect.  
+
+:::
 

docs/risks/Dependency-Risks/Dependency-Risk.md

@@ -13,7 +13,7 @@ tags:
  - Invisibility Risk
  - Risks
 tweet: yes
-slug: /risks/Dependency-Risk
+slug: /risks/Dependency-Risks
 part_of: Operational Risk
 ---
 

docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml → docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml

@@ -1,4 +1,4 @@
 position: 2
 link:
   type: doc
-  id: Scarcity-Risk
+  id: Funding-Risk

docs/risks/Dependency-Risks/Reliability-Risk.md → docs/risks/Dependency-Risks/Reliabiliity-Risk/Reliability-Risk.md

@@ -5,7 +5,7 @@ description: Risks of not getting benefit from a dependency due to it's reliabil
 slug: /risks/Reliability-Risk
 featured: 
   class: c
-  element: '<risk class="dependency" />'
+  element: '<risk class="reliability" />'
 sidebar_position: 1
 tags:
  - Dependency Risk

docs/risks/Dependency-Risks/Reliabiliity-Risk/_category_.yaml

@@ -0,0 +1,4 @@
+position: 1
+link:
+  type: doc
+  id: Reliability-Risk

docs/risks/Dependency-Risks/Scarcity-Risks/Schedule-Risk.md → docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md

@@ -96,6 +96,8 @@ So, as the above diagram shows, the problem with Student Syndrome is that _allow
 
 > _Adding manpower to a late software project makes it later._ - [The Mythical Man-Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)
 
+**See:** [Coordination Risk](/tags/Coordination-Risk)
+
 :::tip Anecdote Corner
 
 I've worked on lots of very large, expensive IT projects.  A general rule is the bigger the project, the less under-control the Schedule Risk will be.  I believe this is because Schedule Risk thrives on complexity.  However in this case I want to talk about a rare case where things went _right_.