diff --git a/docs/practices/Communication-And-Collaboration/Training.md b/docs/practices/Communication-And-Collaboration/Training.md index 39b7c9275..feea80e57 100644 --- a/docs/practices/Communication-And-Collaboration/Training.md +++ b/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 diff --git a/docs/practices/Deployment-And-Operations/Configuration-Management.md b/docs/practices/Deployment-And-Operations/Configuration-Management.md index cdde21749..c63feb060 100644 --- a/docs/practices/Deployment-And-Operations/Configuration-Management.md +++ b/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." diff --git a/docs/practices/Deployment-And-Operations/Demand-Management.md b/docs/practices/Deployment-And-Operations/Demand-Management.md index 23efc8916..2904be35e 100644 --- a/docs/practices/Deployment-And-Operations/Demand-Management.md +++ b/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." diff --git a/docs/practices/Development-And-Coding/Debugging.md b/docs/practices/Development-And-Coding/Debugging.md index 47552fa9b..85697db80 100644 --- a/docs/practices/Development-And-Coding/Debugging.md +++ b/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 diff --git a/docs/practices/Planning-And-Management/Prioritising.md b/docs/practices/Planning-And-Management/Prioritising.md index 089bbf1b5..4040504c6 100644 --- a/docs/practices/Planning-And-Management/Prioritising.md +++ b/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." diff --git a/docs/practices/Planning-And-Management/Requirements-Capture.md b/docs/practices/Planning-And-Management/Requirements-Capture.md index cf09caea4..781751a99 100644 --- a/docs/practices/Planning-And-Management/Requirements-Capture.md +++ b/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 diff --git a/docs/risks/Coordination-Risk/Coordination-Risk.md b/docs/risks/Coordination-Risk/Coordination-Risk.md index 8446afd31..3b7a643f1 100644 --- a/docs/risks/Coordination-Risk/Coordination-Risk.md +++ b/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. + +::: \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk-Elsewhere.md b/docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk-Elsewhere.md similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk-Elsewhere.md rename to docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk-Elsewhere.md diff --git a/docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk-For-Software-Developers.md b/docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk-For-Software-Developers.md similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk-For-Software-Developers.md rename to docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk-For-Software-Developers.md diff --git a/docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk.md b/docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk.md similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/Agency-Risk.md rename to docs/risks/Dependency-Risks/Agency-Risk/Agency-Risk.md diff --git a/docs/risks/Dependency-Risks/Agency-Risks/Reducing-Agency-Risk.md b/docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/Reducing-Agency-Risk.md rename to docs/risks/Dependency-Risks/Agency-Risk/Reducing-Agency-Risk.md diff --git a/docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml b/docs/risks/Dependency-Risks/Agency-Risk/_category_.yaml similarity index 100% rename from docs/risks/Dependency-Risks/Agency-Risks/_category_.yaml rename to docs/risks/Dependency-Risks/Agency-Risk/_category_.yaml diff --git a/docs/risks/Dependency-Risks/Dependency-Risk.md b/docs/risks/Dependency-Risks/Dependency-Risk.md index ce2d80cfd..a81fb0371 100644 --- a/docs/risks/Dependency-Risks/Dependency-Risk.md +++ b/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 --- diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Funding-Risk.md b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md similarity index 100% rename from docs/risks/Dependency-Risks/Scarcity-Risks/Funding-Risk.md rename to docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml b/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml similarity index 61% rename from docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml rename to docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml index da6d60d27..68cdf5241 100644 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/_category_.yaml +++ b/docs/risks/Dependency-Risks/Funding-Risk/_category_.yaml @@ -1,4 +1,4 @@ position: 2 link: type: doc - id: Scarcity-Risk \ No newline at end of file + id: Funding-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Mitigations.md b/docs/risks/Dependency-Risks/Reliabiliity-Risk/Mitigations.md similarity index 100% rename from docs/risks/Dependency-Risks/Scarcity-Risks/Mitigations.md rename to docs/risks/Dependency-Risks/Reliabiliity-Risk/Mitigations.md diff --git a/docs/risks/Dependency-Risks/Reliability-Risk.md b/docs/risks/Dependency-Risks/Reliabiliity-Risk/Reliability-Risk.md similarity index 98% rename from docs/risks/Dependency-Risks/Reliability-Risk.md rename to docs/risks/Dependency-Risks/Reliabiliity-Risk/Reliability-Risk.md index 6c7b0fd01..85528407a 100644 --- a/docs/risks/Dependency-Risks/Reliability-Risk.md +++ b/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: '' + element: '' sidebar_position: 1 tags: - Dependency Risk diff --git a/docs/risks/Dependency-Risks/Reliabiliity-Risk/_category_.yaml b/docs/risks/Dependency-Risks/Reliabiliity-Risk/_category_.yaml new file mode 100644 index 000000000..bfc611dbb --- /dev/null +++ b/docs/risks/Dependency-Risks/Reliabiliity-Risk/_category_.yaml @@ -0,0 +1,4 @@ +position: 1 +link: + type: doc + id: Reliability-Risk \ No newline at end of file diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Opportunity-Risk.md.unused b/docs/risks/Dependency-Risks/Scarcity-Risks/Opportunity-Risk.md.unused deleted file mode 100644 index 55cfffa1f..000000000 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/Opportunity-Risk.md.unused +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Opportunity Risk -description: A particular scarcity risk, due to lack of time. - -featured: - class: c - element: '' -sidebar_position: 2 -tweet: yes -tags: - - Risks - - Funding Risk -part_of: Scarcity Risk ---- - - - - -## Opportunity Risk - -[Opportunity Risk](Scarcity-Risk.md#opportunity-risk) is really the concern that whatever we do, we have to do it _in time_. If we wait too long, we'll miss the [Window Of Opportunity](https://en.wikipedia.org/wiki/Window_of_opportunity) for our product or service. - -Any product idea is necessarily of its time: the [Goal](../thinking/Glossary.md#goal) will be based on observations from a particular [Internal Model](../thinking/Glossary.md#internal-model), reflecting a view on reality at a specific _point in time_. - -How long will that remain true for? This is your _opportunity_: it exists apart from any deadlines you set yourself, or funding options. It's purely, "how long will this idea be worth doing?" - -With any luck, decisions around _funding_ your project will be tied into this, but it's not always the case. It's very easy to under-shoot or overshoot the market completely and miss the window of opportunity. - -### The iPad - -For example, let's look at the [iPad](https://en.wikipedia.org/wiki/History_of_tablet_computers), which was introduced in 2010 and was hugely successful. - -This was not the first tablet computer. Apple had already tried to introduce the [Newton](https://en.wikipedia.org/wiki/Apple_Newton) in 1989, and Microsoft had released the [Tablet PC](https://en.wikipedia.org/wiki/Microsoft_Tablet_PC) in 1999. But somehow, they both missed the [Window Of Opportunity](https://en.wikipedia.org/wiki/Window_of_opportunity). Possibly, the window existed because Apple had changed the market with their release of the iPhone, which left people open to the idea of a tablet being "just a bigger iPhone". - -But maybe now, the iPad's window is closing? We have more _wearable computers_ like the [Apple Watch](https://en.wikipedia.org/wiki/Apple_Watch), and voice-controlled devices like [Alexa](https://en.wikipedia.org/wiki/Amazon_Alexa) or [Siri](https://en.wikipedia.org/wiki/Siri). Peak iPad was in 2014 (according to [this graph at statista.com](https://www.statista.com/statistics/269915/global-apple-ipad-sales-since-q3-2010/)). - -So, it seems Apple timed the iPad to hit the peak of the Window of Opportunity. - -But, even if you time the Window Of Opportunity correctly, you might still have the rug pulled from under your feet due to a different kind of [Scarcity Risk](Scarcity-Risk.md), such as... - diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Red-Queen-Risk.md b/docs/risks/Dependency-Risks/Scarcity-Risks/Red-Queen-Risk.md deleted file mode 100644 index 9256af524..000000000 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/Red-Queen-Risk.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Red Queen Risk -description: The general risk that the competitive environment we operate within changes over time. - -slug: /risks/Red-Queen-Risk - -featured: - class: c - element: '' -sidebar_position: 4 -tweet: yes -tags: - - Risks - - Red Queen Risk -part_of: Scarcity Risk ---- - - - -A more specific formulation of [Schedule Risk](/tags/Schedule-Risk) is [Red Queen Risk](/tags/Red-Queen-Risk), which is that whatever you build at the start of the project will go slowly more-and-more out of date as the project goes on. - -This is named after the Red Queen quote from Alice in Wonderland: - -> “My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” - [Lewis Carroll, _Alice in Wonderland_](https://www.goodreads.com/quotes/458856-my-dear-here-we-must-run-as-fast-as-we) - -The problem with software projects is that tools and techniques change _really fast_. In 2011, 3DRealms released Duke Nukem Forever after [15 years in development](https://en.wikipedia.org/wiki/Duke_Nukem_Forever), to negative reviews: - -> "... most of the criticism directed towards the game's long loading times, clunky controls, offensive humor, and overall aging and dated design. " - _[Duke Nukem Forever, Wikipedia](https://en.wikipedia.org/wiki/Duke_Nukem_Forever)_ - -Now, they didn't _deliberately_ take 15 years to build this game (lots of things went wrong). But, the longer it took, the more their existing design and code-base were a liability rather than an asset. - -![Red Queen Risk](/img/generated/risks/scarcity/red-queen-risk.svg) - -Personally, I have suffered the pain on project teams where we've had to cope with legacy code and databases because the cost of changing them was too high. This is shown in the above diagram: mitigating [Red Queen Risk](/tags/Red-Queen-Risk) (by _keeping up-to-date_) has the [Attendant Risk](/tags/Attendant-Risk) of costing time and money, which might not seem worth it. Any team who is stuck using [Visual Basic 6.0](https://en.wikipedia.org/wiki/Visual_Basic) is here. - -It's possible to ignore [Red Queen Risk](/tags/Red-Queen-Risk) for a time, but this is just another form of [Technical Debt](/tags/Complexity-Risk) which eventually comes due. diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Scarcity-Risk.md b/docs/risks/Dependency-Risks/Scarcity-Risks/Scarcity-Risk.md deleted file mode 100644 index c12dc99dc..000000000 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/Scarcity-Risk.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Scarcity Risk -description: Scarcity Risk is about quantities of a dependency, and specifically, not having enough. - -slug: /risks/Scarcity-Risk - -featured: - class: c - element: '' -sidebar_position: 7 -tweet: yes -tags: - - Risks - - Scarcity Risk -part_of: Dependency Risk ---- - - - -While [Reliability Risk](/tags/Reliability-Risk) (which we met in the previous section) considers what happens when a _single dependency_ is unreliable, scarcity is about _quantities_ of a dependency, and specifically, _not having enough_. - -In the previous section we talked about the _reliability_ of the bus: it will either arrive or it wont. But what if, when it arrives, it's already full of passengers? There is a _scarcity of seats_: you don't much care which seat you get on the bus, you just need one. Let's term this [Scarcity Risk](/tags/Scarcity-Risk), _the risk of not being able to access a dependency in a timely fashion due to its scarcity_. - -Any resource (such as disk space, oxygen, concert tickets, time or pizza) that you depend on can suffer from _scarcity_, and here, we're going to look at five particular types, relevant to software. - -## Types Of Scarcity Risk - - diff --git a/docs/risks/Dependency-Risks/Scarcity-Risks/Schedule-Risk.md b/docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md similarity index 99% rename from docs/risks/Dependency-Risks/Scarcity-Risks/Schedule-Risk.md rename to docs/risks/Dependency-Risks/Schedule-Risk/Schedule-Risk.md index bbd6d76c0..0868ea171 100644 --- a/docs/risks/Dependency-Risks/Scarcity-Risks/Schedule-Risk.md +++ b/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_. diff --git a/docs/risks/Security-Risk.md b/docs/risks/Security-Risk/Security-Risk.md similarity index 100% rename from docs/risks/Security-Risk.md rename to docs/risks/Security-Risk/Security-Risk.md