Fixing software dependency risk

docs/practices/Development-And-Coding/Library-Adoption.md → docs/practices/Development-And-Coding/Dependency-Adoption.md

@@ -1,12 +1,12 @@
 ---
-title: Library Adoption
-description: Implementing code to use libraries or adhere to specific standards.
+title: Dependency Adoption
+description: Making use of software libraries or services as a dependency.
 tags: 
-  - Library Adoption
+  - Dependency Adoption
   - Practice
 featured: 
   class: c
-  element: '<action>Use Library</action>'
+  element: '<action>Use Dependency</action>'
 practice:
   aka: 
    - "Runtime Adoption"
@@ -38,15 +38,13 @@ practice:
 
 ## Description
 
-> "Standardization is the process of implementing and developing technical standards based on the consensus of different parties, including firms, users, interest groups, standards organizations, and governments." - [Standardization, _Wikipedia_](https://en.wikipedia.org/wiki/Standardization)
-
-Adoption of standards and libraries involves implementing and adhering to established standards and integrating widely-used libraries in software development. This practice helps in ensuring consistency, reliability, and maintainability of the software by leveraging proven solutions.
+Making use of third-party libraries or services in your code.
 
 See:
 
  - [Languages and Dependencies](/risks/Complexity-Risk#languages-and-dependencies)
- - [Software Libraries (Software Dependency Risk)](/risks/Software-Dependency-Risk#2-software-libraries)
- - [Software-as-a-Service (Software Dependency Risk)](/risks/Software-Dependency-Risk#3--software-as-a-service)
+ - [Software Libraries (On Software Dependencies)](/risks/On-Software-Dependencies#2-software-libraries)
+ - [Software-as-a-Service (On Software Dependencies)](/risks/On-Software-Dependencies#3--software-as-a-service)
 
 
 ## See Also

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

@@ -44,7 +44,7 @@ practice:
 Standardisation involves creating, implementing, and enforcing standards and guidelines to ensure consistency, compatibility, and quality across software projects. This practice helps in maintaining uniformity, reducing complexity, and improving communication among team members and stakeholders.
 
 See:
-- [Unwritten Software (Software Dependency Risk)](/risks/Software-Dependency-Risk#unwritten-software)
+- [Unwritten Software (On Software Dependencies)](/risks/On-Software-Dependencies#unwritten-software)
 
 
 ## See Also

docs/risks/Complexity-Risk/Complexity-Risk.md

@@ -81,7 +81,7 @@ Although modern languages include plenty of concurrency primitives (such as the
 
 Languages such as [Clojure](https://clojure.org) introduce [persistent collections](https://en.wikipedia.org/wiki/Persistent_data_structure) to alleviate concurrency issues.  The basic premise is that any time you want to _change_ the contents of a collection, you get given back a _new collection_.  So, any collection instance is immutable once created.  The trade-off is again speed to mitigate [Complexity Risk](/tags/Complexity-Risk).  
 
-An important lesson here is that choice of language can reduce complexity: and we'll come back to this in [Software Dependency Risk](/risks/Software-Dependency-Risk).
+An important lesson here is that choice of language can reduce complexity: and we'll come back to this in [On Software Dependencies](/risks/On-Software-Dependencies).
 
 ### 5. Networking / Security
 
@@ -93,7 +93,7 @@ There are plenty of [Complexity Risk](/tags/Complexity-Risk) perils in _anything
 
 Luckily, most good languages include cryptographic libraries that you can include to mitigate these [Complexity Risks](/tags/Complexity-Risk) from your own code-base.  
 
-This is a strong argument for the use of libraries.  But when should you use a library and when should you code-your-own?  This is covered further in the section on [Software Dependency Risk](/risks/Software-Dependency-Risk).  
+This is a strong argument for the use of libraries.  But when should you use a library and when should you code-your-own?  This is covered further in the section on [On Software Dependencies](/risks/On-Software-Dependencies).  
 
 ### 6.  The Pursuit Of Perfection
 

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

@@ -56,7 +56,7 @@ The data processing team needs a new account report to be ready at the start of
  - [Schedule Risk](/tags/Schedule-Risk) is _continuous_, like money.  i.e. you want to waste as little of it as possible.  Every extra day you take compounds [Schedule Risk](/tags/Schedule-Risk) additively. A day wasted at the start of the project is much the same as a day wasted at the end.
  - [Deadline Risk](/tags/Deadline-Risk) is _binary_.  The impact of [Deadline Risk](/tags/Deadline-Risk) is either zero (you make it in time) or one (you are late and miss the flight).  You don't particularly get a reward for being early.
 
-So, these are two separate concepts, both useful in software development and other fields.   Next up, something more specific: [Software Dependency Risk](/risks/Software-Dependency-Risk).
+So, these are two separate concepts, both useful in software development and other fields.  
 
 ## Example Threats
 

docs/risks/Dependency-Risks/Lock-In-Risk/Ecosystems.md

@@ -62,7 +62,7 @@ The above chart is an example of this: look at how the number of public classes
 
 #### Backward Compatibility
 
-As we saw in [Software Dependency Risk](/tags/Software-Dependency-Risk), The art of good design is to afford the greatest increase in functionality with the smallest increase in  complexity possible, and this usually means [Refactoring](https://en.wikipedia.org/wiki/Refactoring).  But, this is at odds with [Backward Compatibility](/risks/Protocol-Risk#backward-compatibility).
+The art of good design is to afford the greatest increase in functionality with the smallest increase in complexity possible, and this usually means [Refactoring](https://en.wikipedia.org/wiki/Refactoring).  But, this is at odds with [Backward Compatibility](/risks/Protocol-Risk#backward-compatibility).
 
 Each new version has a greater functional scope than the one before (pushing back [Lock-In Risk](/tags/Lock-In-Risk)), making the platform more attractive to build solutions in.   But this increases the [Complexity Risk](/tags/Complexity-Risk) as there is more functionality to deal with.  
 

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

@@ -47,7 +47,7 @@ The choice of approach presents us with [Lock-In Risk](/tags/Lock-In-Risk) optio
 
 After having chosen either 'a', 'b' or even our own approach, we have significant sunk costs and are committed to the implementation - changing to another option is going to be expensive and means we have to re-trace our steps.
 
-This is a toy example, but in real life this dilemma occurs when we choose between database vendors, cloud hosting platforms, operating systems, software libraries etc. and is a big factor in our analysis of [Software Dependency Risks](/tags/Software-Dependency-Risk).
+This is a toy example, but in real life this dilemma occurs when we choose between database vendors, cloud hosting platforms, operating systems, software libraries etc. and is a big factor in our analysis of [Software Dependency Risks](/risks/On-Software-Dependencies).
 
 ## Everyday Lock-In Risks
 

docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md → docs/risks/Dependency-Risks/On-Software-Dependencies.md

@@ -1,21 +1,16 @@
 ---
-title: Software Dependency Risks
-description: Specific risks due to relying on software as a dependency.
-
-slug: /risks/Software-Dependency-Risks
-featured: 
-  class: c
-  element: '<risk class="software-dependency" />'
-sidebar_position: 4
+title: On Software Dependencies
+description: Discussion of Dependency Risks due to software.
+
+slug: /risks/On-Software-Dependencies
+sidebar_position: 10
 tweet: yes
 tags: 
- - Software Dependency Risk
+ - Dependency Risk
 ---
 
 In this section, we're going to look specifically at _Software_ dependencies, although many of the concerns we'll raise here apply equally to all the other types of dependency we outlined in [Dependency Risk](/tags/Dependency-Risk). 
 
-![Software Dependency Risk](/img/generated/risks/software-dependency/software-dependency-risk.svg)
-
 In this section we will look at:
 
  - **How Dependencies Provide Features**.   It might seem obvious, but the purpose of adding a software dependency is to _reduce some other kind of risk_.    
@@ -24,9 +19,9 @@ In this section we will look at:
  - **Different Types of Software Dependencies**.   In a software project there are a number of ways you could depend on _other software_.  Here, we break it down into some specific types (write-your-own, libraries and services) and look at the risk characteristics of each.
  - Finally, we look at how software dependencies are **Funded** - that is, how they survive over time.  Here we focus on Open Source, Commercial and Ad-Supported options, and the risks introduced by each.
 
-## Software Dependencies as Features
+## Software Dependencies Mitigate Risks
 
-[Software Dependencies](/tags/Software-Dependency-Risk) allows us to construct dependency networks to give us all kinds of features and mitigate all kinds of risk.  That is, the features we are looking for in a dependency _are to mitigate some kind of risk_.
+[Software Dependencies](/tags/Dependency-Adoption) allows us to construct dependency networks to give us all kinds of features and mitigate all kinds of risk.  That is, the features we are looking for in a dependency _are to mitigate some kind of risk_.
 
 For example, I might start using [WhatsApp](https://en.wikipedia.org/wiki/WhatsApp) because I want to be able to send my friends photos and text messages.  However, it's likely that those same features allow us to mitigate [Coordination Risk](/tags/Coordination-Risk) when we're next trying to meet up. 
 
@@ -42,7 +37,7 @@ Let's look at some more examples:
 |[Operational-Risk](/tags/Operational-Risk)                 |Support tools like ZenDesk, Grafana, InfluxDB, Geneos, Security Tools     |
 |[Feature-Risk](/tags/Feature-Risk)                         |Every piece of software you use!                                          |
 
-With this in mind, we can see that adding a software dependency is a trade-off:  we reduce some risk (as in the table above), but in return we pick up [Software Dependency Risk](/tags/Software-Dependency-Risk) as a result.  Whether this trade-off is worth it depends entirely on how well that software dependency resolves the original risk and how onerous the new risks are that we pick up.
+With this in mind, we can see that adding a software dependency is a trade-off:  we reduce some risk (as in the table above), but in return we pick up [Dependency Risk](/tags/Dependency-Risks) as a result.  Whether this trade-off is worth it depends entirely on how well that software dependency resolves the original risk and how onerous the new risks are that we pick up.
 
 ## Programming Languages as Dependencies
 

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

@@ -94,7 +94,7 @@ This kind of stuff is encapsulated in the science of [Reliability Engineering](h
 
 This was applied on NASA missions, and then in the 1970's to car design following the Ford Pinto exploding car (see below).  But establishing the reliability of software dependencies like this would be _hard_ and _expensive_.  We are more likely to mitigate [Reliability Risk](/tags/Reliability-Risk) in software using [performance testing](/tags/Performance-Testing) or [redundancy](/tags/Redundancy) as shown in the diagram above.  
 
-Additionally, we often rely on _proxies for reliability_.  We'll look at these proxies (and the way in which software projects signal their reliability) in much more detail in the section on [Software Dependency Risk](/tags/Software-Dependency-Risk).
+Additionally, we often rely on _proxies for reliability_.  We'll look at these proxies (and the way in which software projects signal their reliability) in much more detail in the section on [Software Dependency Risks](/risks/On-Software-Dependencies).
 
 :::tip Anecdote Corner
 

docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md

@@ -101,6 +101,6 @@ The "should we ship?" decision is therefore a complex one.  In [Meeting Reality]
 
 ## The End Of The Road
 
-In a way, [actions](/tags/Take-Action) like [Design](/tags/Design) and [Development](/tags/Coding) bring us right back to where we started from: identifying [Dependency Risks](/tags/Dependency-Risk), [Feature Risks](/tags/Feature-Risks) and [Complexity Risks](/tags/Complexity-Risk) that hinder our operation, and mitigating them through actions like _software development_.  
+In a way, [actions](/tags/Take-Action) like [Design](/tags/Design) and [Development](/tags/Coding) bring us right back to where we started from: identifying [Dependency Risks](/tags/Dependency-Risks), [Feature Risks](/tags/Feature-Risks) and [Complexity Risks](/tags/Complexity-Risk) that hinder our operation, and mitigating them through actions like _software development_.  
 
 Our safari of risk is finally complete: it's time to reflect on what we've seen in the next section, [Staging and Classifying](Staging-And-Classifying).  

docs/risks/Risk-Landscape.md

@@ -59,7 +59,6 @@ Below is a table outlining the different risks we'll see.  There _is_ an order t
 |[Dependency Risks](/tags/Dependency-Risks)                  |Risks of depending on other people, products, software, functions, etc. This is a general look at dependencies, before diving into specifics like...|  
 |[Scarcity Risk](/tags/Scarcity-Risk)                      |Risks associated with having limited time, money or some other resource.|    
 |[Deadline Risk](/tags/Deadline-Risk)                      |The risk of creating a dependency around a point in time.|
-|[Software Dependency Risk](/tags/Software-Dependency-Risk)|The risk of depending on a software library, service or function.|    
 |[Process Risk](/tags/Process-Risk)                        |When you depend on a business process, or human process to give you something you need.|
 |[Lock-In Risk](/tags/Lock-In-Risk)                      |Risks due to making decisions that limit your choices later on.  Sometimes, you go the wrong way on the [Risk Landscape](/risks/Risk-Landscape) and it's hard to get back to where you want to be.|            
 |[Agency Risk](/tags/Agency-Risk)                          |Risks that staff have their own [Goals](/tags/Goal), which might not align with those of the project or team.|

docs/tags.yml

@@ -227,9 +227,9 @@
   label: "Runtime Adoption"
   permalink: "Runtime-Adoption"
 
-"Library Adoption":
-  label: "Library Adoption"
-  permalink: "Library Adoption"
+"Dependency Adoption":
+  label: "Dependency Adoption"
+  permalink: "Dependency Adoption"
 
 "Sales":
   label: "Sales"

docs/thinking/De-Risking.md

@@ -101,7 +101,7 @@ The table above lists a set of _generic strategies_ for derisking which we'll lo
 
 1.  **Do Risky Things Early**:  If you are building some software process which has ten steps in it, and the 9th step has a high probability of not being implementable, then _build the 9th step first_.  If you succeed, you've massively reduced the risk of the process construction.  IF you fail, you'll only have lost the time it took to build that one step.  _Build a proof of concept_.
 
-1.  **Take Care With Dependencies**: Choose popular technologies and known reliable components. Whilst hiring people is hard work at the best of times, hiring PL/1 programmers is _really hard_. This tactic is explored in much more depth in [Software Dependency Risk](/risks/Software-Dependency-Risk)
+1.  **Take Care With Dependencies**: Choose popular technologies and known reliable components. Whilst hiring people is hard work at the best of times, hiring PL/1 programmers is _really hard_. This tactic is explored in much more depth in [On Software Dependencies](/risks/On-Software-Dependencies)
 
 1.  **Redundancy**: Avoid single points of failure.   For example, Pair Programming is a control espoused by [Extreme Programming](/tags/Extreme-Programming) to reduce [Key Person Risk](/tags/Agency-Risk) and [Communication Risk](/tags/Communication-Risk).  See [Dependency Risks](/tags/Dependency-Risks) for more on this.