From 028ce481d96b6393185b688bdc8ece122faf795a Mon Sep 17 00:00:00 2001 From: Rob Moffat Date: Sat, 11 Jan 2025 17:27:05 +0000 Subject: [PATCH] Removed scarcity risks --- docs/estimating/Kitchen-Cabinet.md | 4 ++-- .../Deployment-And-Operations/Demand-Management.md | 2 +- docs/risks/Complexity-Risk/Complexity-Analogies.md | 9 +++------ docs/risks/Complexity-Risk/Connectivity.md | 1 - docs/risks/Complexity-Risk/Hiding-Places.md | 4 ---- .../Coordination-Risk/A-Model-Of-Coordination-Risk.md | 2 +- docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md | 2 +- docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md | 3 +-- .../Dependency-Risks/Reliability-Risk/Mitigations.md | 4 ++-- .../Operational-Risk/Operations-Management.md | 6 +++--- docs/risks/Risk-Landscape.md | 1 - 11 files changed, 14 insertions(+), 24 deletions(-) diff --git a/docs/estimating/Kitchen-Cabinet.md b/docs/estimating/Kitchen-Cabinet.md index d74e461f0..d33137a38 100644 --- a/docs/estimating/Kitchen-Cabinet.md +++ b/docs/estimating/Kitchen-Cabinet.md @@ -114,7 +114,7 @@ Is lambda predictable on a project? It doesn't appear that there have been any ### When Does Risk Happen? -Too-early and too-late risks are both [Scarcity Risks](/risks/(/tags/Scarcity-Risk): they reflect the fact that time/budget/staff/opportunity are scarce resources which you can run out of. +Too-early and too-late risks are both [Dependency Risks](/risks/(/tags/Dependency-Risks): they reflect the fact that time/budget/staff/opportunity are scarce resources which you can run out of. But where is the risk accrued? If you give an estimate, you lock in a maximum too-early risk _at that point_. From then on, the clock is ticking: too-early risk decreases towards zero as the due-date approaches. @@ -144,7 +144,7 @@ This means that clients often keep projects running for far longer than they sho There is an alternative to too-early or too-late risk. You can always choose to be _on time_. This is definitely a choice: Just like a student can always hand _something_ in on assignment day (even if it's just a title scrawled on a piece of paper), you can always hand in whatever work you have. -Then, instead of worrying about [Scarcity Risks](/risks/(/tags/Scarcity-Risk), you are letting [Feature Fit Risk](/tags/Feature-Risk) vary to take up the slack. +Then, instead of worrying about [Deadline Risk](/risks/(/tags/Deadline-Risk), you are letting [Feature Fit Risk](/tags/Feature-Risk) vary to take up the slack. So far, we've seen two kinds of estimate: [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet). Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Risk) within an available budget. diff --git a/docs/practices/Deployment-And-Operations/Demand-Management.md b/docs/practices/Deployment-And-Operations/Demand-Management.md index a0e3a0ca6..7c6e1113f 100644 --- a/docs/practices/Deployment-And-Operations/Demand-Management.md +++ b/docs/practices/Deployment-And-Operations/Demand-Management.md @@ -43,7 +43,7 @@ TODO: buffers, queues, pools, kanban See: -- [Scarcity Risk](/risks/Dependency-Risks/Scarcity-Risks/Mitigations) +- [Reliability Risk](/risks/Reliability-Risk) ## See Also diff --git a/docs/risks/Complexity-Risk/Complexity-Analogies.md b/docs/risks/Complexity-Risk/Complexity-Analogies.md index 0c47d11a8..9bb91244e 100644 --- a/docs/risks/Complexity-Risk/Complexity-Analogies.md +++ b/docs/risks/Complexity-Risk/Complexity-Analogies.md @@ -3,14 +3,11 @@ sidebar_position: 3 title: Analogies For Complexity --- - -## Analogies - So, we've looked at some measures of software structure complexity. We can say "this is more complex than this" for a given piece of code or structure. We've also looked at three ways to manage it: [Abstraction](/tags/Abstraction) and [Modularisation](/risks/Complexity-Risk#hierarchies-and-modularisation) and via [Dependencies](/risks/Complexity-Risk#languages-and-dependencies). However, we've not really said why complexity entails [Risk](/tags/Attendant-Risk). So let's address that now by looking at three analogies, [Mass](/risks/Complexity-Risk#complexity-is-mass), [Technical Debt](/risks/Complexity-Risk#technical-debt) and [Mess](/risks/Complexity-Risk#kitchen-analogy) -### Complexity is Mass +## Complexity is Mass The first way to look at complexity is as **Mass** : a software project with more complexity has greater mass than one with less complexity. @@ -32,7 +29,7 @@ If we want to move _fast_ we need simple code-bases. At a basic level, [Complexity Risk](/tags/Complexity-Risk) heavily impacts on [Schedule Risk](/tags/Schedule-Risk): more complexity means you need more force to get things done, which takes longer. -### Technical Debt +## Technical Debt The most common way we talk about [Complexity Risk](/tags/Complexity-Risk) in software is as [Technical Debt](/risks/Complexity-Risk#technical-debt): @@ -58,7 +55,7 @@ It's not long before someone comes down with food poisoning. We wouldn't tolerate this behaviour in a restaurant kitchen, so why put up with it in a software project? This state-of-affairs is illustrated in the above diagram. Not only does [Complexity Risk](/tags/Complexity-Risk) slow down future development, it can be a cause of [Operational Risks](/tags/Operational-Risk) and [Security Risks](Agency-Risk#security). -### Feature Creep +## Feature Creep In Brooks' essay "No Silver Bullet - Essence and Accident in Software Engineering", a distinction is made between: diff --git a/docs/risks/Complexity-Risk/Connectivity.md b/docs/risks/Complexity-Risk/Connectivity.md index 5fcc2e7f1..feac1d160 100644 --- a/docs/risks/Complexity-Risk/Connectivity.md +++ b/docs/risks/Complexity-Risk/Connectivity.md @@ -3,7 +3,6 @@ sidebar_position: 2 title: Connectivity As Complexity --- - A second useful measure of complexity comes from graph theory, and that is the connectivity of a graph: > "...the minimum number of elements (nodes or edges) that need to be removed to disconnect the remaining nodes from each other" - [Connectivity, _Wikipedia_](https://en.wikipedia.org/wiki/Connectivity_(graph_theory)) diff --git a/docs/risks/Complexity-Risk/Hiding-Places.md b/docs/risks/Complexity-Risk/Hiding-Places.md index 10a5f4115..17e8bde45 100644 --- a/docs/risks/Complexity-Risk/Hiding-Places.md +++ b/docs/risks/Complexity-Risk/Hiding-Places.md @@ -3,10 +3,6 @@ sidebar_position: 4 title: Hiding Places --- - - -## Where Complexity Hides - So far, we've focused mainly on [Codebase Risk](/tags/Codebase-Risk), but this isn't the only place complexity appears in software. We're going to cover a few of these areas now, but be warned, this is not a complete list by any means: - Algorithmic (Space and Time) Complexity diff --git a/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md b/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md index b25b29e42..5bd57ad7b 100644 --- a/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md +++ b/docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md @@ -5,7 +5,7 @@ sidebar_position: 1 ## A Model Of Coordination Risk -Earlier, when looking at [Dependency Risks](/tags/Dependency-Risks), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risks) taking on risk. Here, let's consider the situation where there is _competition for those dependencies_ due to [Scarcity Risk]((/tags/Scarcity-Risk): other agents want to use them in a different way. +Earlier, when looking at [Dependency Risks](/tags/Dependency-Risks), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risks) taking on risk. Here, let's consider the situation where there is _competition for those dependencies_: other agents want to use them in a different way. ### Law Of Diminishing Returns diff --git a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md index c702edef4..a3b5770d2 100644 --- a/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md +++ b/docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md @@ -1,6 +1,6 @@ --- title: Funding Risk -description: A particular scarcity risk, due to lack of funding. +description: A particular dependency-scarcity risk, due to lack of funding. slug: /risks/Funding-Risk diff --git a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md index 4a955c658..9c75dae76 100644 --- a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md +++ b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md @@ -22,9 +22,8 @@ part_of: Dependency Risks Process Risk intersects with several other types of risk we've covered so far: -- [Scarcity Risk](/tags/Scarcity-Risk): Processes may become scarce when they lack resources (think of CPU bottlenecks or queues at the post-office counter). - [Agency Risk](/tags/Agency-Risk): Processes have their own agency - they often involve decision making (a loan application or passport renewal). -- [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example). +- [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example) or unavailable when they lack resources (think of CPU bottlenecks or queues at the post-office counter).. - [Communication Risk](/tags/Communication-Risk): You need to communicate intent to the process, and have it report back its status (think of buying something on the Internet, and the delivery company communicating where the parcel is in transit). - [Feature Fit Risk](/tags/Feature-Fit-Risk): A Process should be supplying some useful _features_ to you in order for you to use it. Is it fit for purpose? (An example might be starting to fill out a form but then realising you're filling out the wrong form). diff --git a/docs/risks/Dependency-Risks/Reliability-Risk/Mitigations.md b/docs/risks/Dependency-Risks/Reliability-Risk/Mitigations.md index 614cfcb1c..c8647f578 100644 --- a/docs/risks/Dependency-Risks/Reliability-Risk/Mitigations.md +++ b/docs/risks/Dependency-Risks/Reliability-Risk/Mitigations.md @@ -1,12 +1,12 @@ ## Mitigations -Here are a selection of mitigations for [Scarcity Risk](/tags/Scarcity-Risk) in general: +Here are a selection of mitigations for scarcity in general: - **Buffers**: smoothing out peaks and troughs in utilisation. - **Reservation Systems**: giving clients information _ahead_ of the dependency usage about whether the resource will be available to them. - **Graceful degradation**: ensuring _some_ service in the event of over-subscription. It would be no use allowing people to cram onto the bus until it can't move. - - **Demand Management**: having different prices during busy periods helps to reduce demand. Having "first class" seats means that higher-paying clients can get service even when the train is full. [Uber](https://www.uber.com) adjust prices in real-time by so-called [Surge Pricing](https://www.uber.com/en-GB/drive/partner-app/how-surge-works/). This is basically turning [Scarcity Risk](/tags/Scarcity-Risk) into a [Market Risk](/tags/Market-Risk) problem. + - **Demand Management**: having different prices during busy periods helps to reduce demand. Having "first class" seats means that higher-paying clients can get service even when the train is full. [Uber](https://www.uber.com) adjust prices in real-time by so-called [Surge Pricing](https://www.uber.com/en-GB/drive/partner-app/how-surge-works/). This is basically turning scarcity into a [Market Risk](/tags/Market-Risk) problem. - **Queues**: these provide a "fair" way of dealing with scarcity by exposing some mechanism for prioritising use of the resource. Buses operate a first-come-first-served system, whereas emergency departments in hospitals triage according to need. - **Pools**: reserving parts of a resource for a group of customers, and sharing within that group. - **Horizontal Scaling**: allowing a scarce resource to flexibly scale according to how much demand there is. (For example, putting on extra buses when the trains are on strike, or opening extra check-outs at the supermarket.) diff --git a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md index dee0eb946..7f83568e1 100644 --- a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md +++ b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md @@ -77,7 +77,7 @@ In recent years the [DevOps](https://en.wikipedia.org/wiki/DevOps) movement has ## Improvement -No system can be perfect, and after it meets the real world, we will want to improve it over time. But [Operational Risk](/tags/Operational-Risk) includes an element of [Trust & Belief Risk](/tags/Trust-And-Belief-Risk): we have a _reputation_ and the good will of our customers to consider when we make improvements. Because this is very hard to rebuild, we should consider this before releasing software that might not live up to expectations. +No system can be perfect, and after it meets the real world, we will want to improve it over time. But [Operational Risk](/tags/Operational-Risk) includes an element of [Reputational Risk](/tags/Reputational-Risk): we have a _reputation_ and the good will of our customers to consider when we make improvements. Because this is very hard to rebuild, we should consider this before releasing software that might not live up to expectations. So there is a tension between "you only get one chance to make a first impression" and "gilding the lily" (perfectionism). In the past I've seen this stated as _pressure to ship vs pressure to improve_. @@ -85,8 +85,8 @@ So there is a tension between "you only get one chance to make a first impressio A Risk-First re-framing of this (as shown in the diagram above) might be the balance between: -- The perceived [Scarcity Risks](/tags/Scarcity-Risk) (such as funding, time available, etc) of staying in development (pressure to ship). -- The perceived [Trust & Belief Risk](/tags/Trust-And-Belief-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve). +- The perceived scarcity (such as funding, time available, etc) of staying in development (pressure to ship). +- The perceived [Reputational Risk](/tags/Reputational-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve). The "should we ship?" decision is therefore a complex one. In [Meeting Reality](/thinking/Meeting-Reality), we discussed that it's better to do this "sooner, more frequently, in smaller chunks and with feedback". We can meet [Operational Risk](/tags/Operational-Risk) _on our own terms_ by doing so: diff --git a/docs/risks/Risk-Landscape.md b/docs/risks/Risk-Landscape.md index bf538fd69..0ee8b8313 100644 --- a/docs/risks/Risk-Landscape.md +++ b/docs/risks/Risk-Landscape.md @@ -57,7 +57,6 @@ Below is a table outlining the different risks we'll see. There _is_ an order t |[Communication Risk](/tags/Communication-Risk) |Risks associated with getting messages heard and understood.| |[Complexity Risk](/tags/Complexity-Risk) |Your software is so complex it makes it hard to change, understand, or run. | |[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.| |[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.|