Internal Model Risk

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

@@ -12,13 +12,17 @@ practice:
    - "Post-Mortem"
    - "After-Action Review"
    - "Lessons Learned"
+   - "Oversight"
+   - "Governance"
   mitigates:
    - tag: Coordination Risk
      reason: "Identifies and addresses coordination issues through regular reviews."
    - tag: Process Risk
      reason: "Continuously improves processes and practices."
    - tag: Feature-Drift Risk
      reason: "Captures feedback and adjusts features to meet evolving needs."
+   - tag: Internal Model Risk
+     reason: "Looking at what went wrong before leads to improving the internal model of risk for the future."
   attendant:
    - tag: Schedule Risk
      reason: "Requires coordination and can disrupt regular workflows."

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

@@ -22,7 +22,7 @@ practice:
      reason: "Identifies unnecessary complexity and communicates necessary complexity to the rest of the team."
    - tag: Agency Risk
      reason: "Reviewing work or activity can ensure good behaviour."
-   - tag: Map And Territory Risk
+   - tag: Internal Model Risk
      reason: "Reviews and audits can uncover unseen problems in a system"
   attendant:
    - tag: Schedule Risk

docs/practices/Deployment-And-Operations/Automation.md

@@ -32,8 +32,8 @@ practice:
      reason: Automated processes have their own agency and might not work as desired.
    - tag: Security Risk
      reason: Automation can introduce security issues if automated processes are given elevated privileges.  
-   - tag: Map And Territory Risk
-     reason: "Automation of reporting and status can hide the truth of a system's health."
+   - tag: Internal Model Risk
+     reason: "Automation of reporting and statuses can lead to false confidence about a system's health."
   related:
    - ../Development-And-Coding/Coding
    - ../Tools-And-Standards/Measurement

docs/practices/External-Relations/Analysis.md

@@ -21,6 +21,8 @@ practice:
      reason: "Analysis can help ensure technical solutions fit the problems they're designed for."
    - tag: Contextual Risk
      reason: "Developing an understanding the context into which a solution is put avoids legal and social problems."
+   - tag: Internal Model Risk
+     reason: "Analysis is the process of doign work to build a better Internal Model."
   attendant:
    - tag: Schedule Risk
      reason: "Can be time-consuming, potentially delaying the start of development."

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

@@ -18,7 +18,10 @@ practice:
    - tag: Coordination Risk
      reason: "Allows stakeholders to coordinate on their work and demands."
    - tag: Communication Risk
-     reason: "Facilitates clear and consistent communication between stakeholders."    
+     reason: "Facilitates clear and consistent communication between stakeholders."  
+   - tag: Internal Model Risk
+     reason: "Talking to stakeholders helps to share and socialise Internal Models." 
+
   attendant:
    - tag: Coordination Risk
      reason: "Requires effective coordination among all stakeholders, which can be challenging."

docs/practices/Testing-and-Quality-Assurance/Automated-Testing.md

@@ -25,8 +25,8 @@ practice:
      reason: "Managing a large suite of unit tests can add to the complexity."
    - tag: Software Dependency Risk
      reason: "Creates dependencies on testing frameworks and tools."
-   - tag: Map And Territory Risk
-     reason: "Unit Testing and code coverage doesn't reflect how a system will work when assembled."
+   - tag: Internal Model Risk
+     reason: "Unit Testing and code coverage can give false assurances about how a system will work in the real world."
   related:
    - ../Testing-and-Quality-Assurance/Integration-Testing
    - ../Development-and-Coding/Coding

docs/practices/Testing-and-Quality-Assurance/Measurement.md

@@ -26,7 +26,7 @@ practice:
      reason: "Creates dependencies on measurement tools and their accuracy."
    - tag: Complexity Risk
      reason: "Collecting and analyzing data can add to the complexity of the project."
-   - tag: Map And Territory Risk
+   - tag: Internal Model Risk
      reason: "Focusing on the wrong measures can blind you to what's important."
   related:
    - ../Deployment-and-Operations/Monitoring

docs/practices/Testing-and-Quality-Assurance/Performance-Testing.md

@@ -22,8 +22,8 @@ practice:
      reason: "Requires sophisticated tools and setup, adding complexity."
    - tag: Funding Risk
      reason: "Performance testing tools and environments can be expensive."
-   - tag: Map And Territory Risk
-     reason: "Performance testing might not be reflecting real-world scenarios."
+   - tag: Internal Model Risk
+     reason: "Performance testing might give a false confidence and not reflect real-world scenarios."
   related:
    - ../Development-and-Coding/Coding
    - ../Testing-and-Quality-Assurance/Integration-Testing

docs/practices/Testing-and-Quality-Assurance/User-Acceptance-Testing.md

@@ -22,6 +22,8 @@ practice:
      reason: "Validates that the implementation meets the specified requirements."
    - tag: Communication Risk
      reason: "Facilitates feedback from end users, improving the final product."
+   - tag: Internal Model Risk
+     reason:  "As a feedback mechanism, UAT helps improve understanding of users and their requirements."
   attendant:
    - tag: Schedule Risk
      reason: "UAT can be time-consuming, potentially delaying the release."

docs/risks/Communication-Risks/Reading-Code.md

@@ -0,0 +1,18 @@
+
+If the messages we are receiving force us to update our [Internal Model](/tags/Internal-Model) too much, we can suffer from the problem of "too steep a [Learning Curve](https://en.wikipedia.org/wiki/Learning_curve)" or "[Information Overload](https://en.wikipedia.org/wiki/Information_overload)", where the messages force us to adapt our [Internal Model](/tags/Internal-Model) too quickly for our brains to keep up.  
+
+Commonly, the easiest option is just to ignore the information channel completely in these cases.
+
+#### Reading Code
+
+It has often been said that code is _harder to read than to write_:  
+
+> "If you ask a software developer what they spend their time doing, they'll tell you that they spend most of their time writing code.  However, if you actually observe what software developers spend their time doing, you'll find that they spend most of their time trying to understand code. " -  [When Understanding Means Rewriting, _Coding Horror_](https://blog.codinghorror.com/when-understanding-means-rewriting/)
+
+By now it should be clear that it's going to be _both_ quite hard to read and write:  the protocol of code is actually designed for the purpose of machines communicating, not primarily for people to understand.  Making code human-readable is a secondary concern to making it machine-readable.
+
+But now we should be able to see the reason why it's harder to read than write too: 
+
+ - When reading code, you are having to shift your [Internal Model](/tags/Internal-Model) to wherever the code is, accepting decisions that you might not agree with and accepting counter-intuitive logical leaps.  i.e. [Learning Curve Risk](/tags/Learning-Curve-Risk). _(cf. [Principle of Least Surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment))_
+ - There is no [Feedback Loop](/tags/Feedback-Loop) between your [Internal Model](/tags/Internal-Model) and the [Reality](/tags/Meeting-Reality) of the code, opening you up to [misinterpretation](/risks/Message-Risk#misinterpretation).  When you write code, your compiler and tests give you this.
+ - While reading code _takes less time_ than writing it, this also means the [Learning Curve](/tags/Learning-Curve-Risk) is steeper.

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

@@ -1,6 +1,6 @@
 ---
 title: Schedule Risk
-description: The aspect of dependency risk related to lack of time.
+description: The aspect of dependency risk related to variance around the time taken to complete tasks on a schedule.
 
 slug: /risks/Schedule-Risk
 
@@ -22,17 +22,20 @@ part_of: Scarcity Risk
 
 So [Schedule Risk](/tags/Schedule-Risk) is the risk around schedules we try to impose on our work, usually because we cannot know _a priori_ how long a piece of work will take.  Unrealistically low estimates are therefore the source of [Schedule Risk](/tags/Schedule-Risk): the more aggressive the estimate, the more risk you are running, even though every now and again you might win the estimation lottery and find _just the right piece_ of open source code to take a short-cut through time and hit the estimate.
 
+Some developers take the view that [estimates aren't necessary](https://ronjeffries.com/xprog/articles/the-noestimates-movement/) and sometimes perhaps they aren't.  However at a basic level this doesn't stand up to scrutiny:  you do need to know whether a piece of work is worth embarking on.  Will it take a day?  A week?  A month?   A year?  The answer to this question fundamentally affects the value of the work that is being undertaken.  In the case where multiple alternative solutions are possible, using your [internal model](tags/Internal-Model) to estimate the cost of each may be a key way to decide which path to follow.  
+
+**See:** This is a topic that is covered in depth in the section on [Estimating](/estimating/Start) in Risk-First.
+
 :::note
 
-You'll notice that I've split out [Schedule Risk](/tags/Schedule-Risk) from [Deadline Risk](/tags/Deadline-Risk).  They're slightly different things, and often, a schedule will include a deadline to meet at the end of it.  However, from my experience in software development _schedule slippage_ has a different quality to _missed deadlines_.  So it's worth looking at how these two things differ:   
+You'll notice that I've split out [Schedule Risk](/tags/Schedule-Risk) from [Deadline Risk](/tags/Deadline-Risk).  They're slightly different things, and often, as scheduling and estimating will often generate a deadline to meet.  However, from my experience in software development _schedule slippage_ has a different quality to _missed deadlines_.  So it's worth looking at how these two things differ:   
 
 - [Deadline Risk](/tags/Deadline-Risk) is the risk you face from missing a deadline.  
 
 - [Schedule Risk](/tags/Schedule-Risk) occurs when things take longer to complete than you have scheduled for them.   We'll discuss reasons this happens below.
 
 :::
 
-
 ## Worked Example
 
 With [Schedule Risk](/tags/Schedule-Risk), the underlying measure is _time_ and our inability to be precise about how long things might take.
@@ -41,12 +44,23 @@ So many things affect schedule risk:  The more work you try to implement, the mo
 
 ![Schedule Risk 1](/img/generated/risks/posters/schedule-risk1.svg)
 
-In the example above, a team are working to produce new features for their clients, however there are complaints of bugs.   The team diagnose the problem down to some design choices in the codebase which have cascaded down into much more complex code than is necessary.  They decide to [refactor the code](/tags/Refactoring), aware that by doing this they are embarking on a task that may be much more long-winded than they anticipate.
+In the example above, a team are working to produce new features for their clients, however there are complaints that the features aren't quite what is needed and the team is slow to deliver.   The team diagnose the problem down to some design choices in the codebase which have cascaded down into much more complex code than is necessary.  They decide to [refactor the code](/tags/Refactoring), aware that by doing this they are embarking on a hard-to-estimate task that may be much more long-winded than they anticipate.
 
 ![Schedule Risk 2](/img/generated/risks/posters/schedule-risk2.svg)
 
-Conversely, a team might work to _reduce_ schedule risk:  In the diagram above, a team realises that it is terrible at estimating and lots of development tasks are running longer than expected.  In order to bring discipline to the team, the manager adds [Pressure](/tags/Pressure) (perhaps in the form of punishments for late delivery or bonuses for on-time delivery).  Suddenly, work _is_ completed according to the set schedule.  But corners are cut and [complexity](/tags/Complexity-Risk) and [bugs](/tags/Implementation-Risk) creep in.
+Conversely, a team might work to _reduce_ schedule risk:  In the diagram above, a team realises that it is terrible at estimating and lots of development tasks are running longer than expected.  In order to bring discipline to the team, the manager adds [Pressure](/tags/Pressure) (perhaps in the form of punishments for late delivery or bonuses for on-time delivery).  Suddenly, work _is_ completed according to the set schedule.  But corners are cut and [bugs](/tags/Implementation-Risk) creep in.
+
+### Student Syndrome and Procrastination
+
+An obvious way to reduce [Schedule Risk](/tags/Schedule-Risk) would appear to be to just pad the estimates.  However, there is a problem with this.  [Student Syndrome](https://en.wikipedia.org/wiki/Student_syndrome) is, according to Wikipedia:
 
+> "Student syndrome refers to planned procrastination, when, for example, a student will only start to apply themselves to an assignment at the last possible moment before its deadline."   - _[Wikipedia](https://en.wikipedia.org/wiki/Student_syndrome)_
+
+Arguably, there is good psychological, evolutionary and risk-based reasoning behind procrastination:  if there is apparently a lot of time to get a job done, then [Schedule Risk](/tags/Schedule-Risk) is low.  If we're only ever mitigating our _biggest risks_, then managing [Schedule Risk](/tags/Schedule-Risk) in the future doesn't matter so much.  Putting efforts into mitigating future risks that _might not arise_ is wasted effort.
+
+![Schedule Risk 3](/img/generated/risks/posters/schedule-risk3.svg)
+
+So, as the above diagram shows, the problem with Student Syndrome is that _allowing more time_ in order to reduce [Schedule Risk](/tags/Schedule-Risk)  is an [Attendant Risk](/tags/Attendant-Risk) that _causes_ [Schedule Risk](/tags/Schedule-Risk):  within the more generous time allocation wortk proceeds either more slowly and perhaps more thoroughly, or starts later, so you'll end up revealing [Hidden Risk](/tags/Hidden-Risk) _later_.  Discovering these hidden risks later pushes out the completion date anyway.
 
 ## Example Threats
 
@@ -56,8 +70,6 @@ Conversely, a team might work to _reduce_ schedule risk:  In the diagram above,
 
 **Threat**: The estimating process is compromised by deadlines or social pressure, making it hard to  
 
-**See:**  The section on [Estimating](/estimating/Start)
-
 ### 2.  Hidden Risks / Technical Challenges
 
 **Threat**:  You're working in a new area and therefore have an under-developed [Internal Model](/tags/Internal-Model) of the domain.
@@ -72,7 +84,7 @@ Conversely, a team might work to _reduce_ schedule risk:  In the diagram above,
 
 **Mitigation**: Try to identify those up-front to begin them early.
 
-### 4.  Slack
+### 4.  Slack and Procrastination
 
 **Threat**: [Parkinson's Law](https://en.wikipedia.org/wiki/Parkinson's_law) says that work expands to fill the time available.  Therefore _padding estimates_ only works so long as there is the illusion that _there isn't time available_,   
 
@@ -94,7 +106,7 @@ However, at some point a lot of the political players moved on to something else
 
 This compares to being members of the original 7-strong team for well over a year beforehand and getting a lot less done. 
 
-But the only reason this was allowed to happen was because we'd been bullish in our estimates:  the original DAS was over-encumbered with technical debt and was therefore too hard to change and improve.  We estimated it would take two months to implement the new design and it did.  This was both an educated guess plus a lot of luck.
+But the only reason this was allowed to happen was because we'd been bullish in our estimates:  the original DAS was over-encumbered with technical debt and was therefore too hard to change and improve.  We estimated it would take two months to implement the new design and it did.  This was both an educated guess - we knew the scope of the problem well and the tools we intended to use to solve it - plus some luck.
 
 
 :::