Fixed broken links phase 1

docs/bets/Coding-Bets.md

@@ -132,12 +132,12 @@ The idea here is to make a bet that a market exists for a certain product, _and
 
 We're used to the idea of entrepreneurs taking risks on new business ideas (like in the MVP example, above).  But it's not really so different when you are developing in a team, or on a personal project.  So if you start by taking the view that every piece of work you do is a bet then it really helps to put into perspective what is at stake and what is to gain.  
 
-The best gamblers (the ones who win over time) don't necessarily take bets they'll always win.  But they are always judging risk, stake and reward.  They try to place bets where the [Balance of Risk](/thinking/Glossary.md#balance-of-risk) is in their favour.   As developers, we should adopt the same mind-set:
+The best gamblers (the ones who win over time) don't necessarily take bets they'll always win.  But they are always judging risk, stake and reward.  They try to place bets where the [Balance of Risk](/thinking/Glossary#balance-of-risk) is in their favour.   As developers, we should adopt the same mind-set:
 
  - What are the likely stakes?
- - What is the [Payoff](/thinking/Glossary.md#payoff)?
+ - What is the [Payoff](/thinking/Glossary#payoff)?
  - What are the odds?
- - Is the bet worth it?  Do the stakes justify the [Payoff](/thinking/Glossary.md#payoff)?
+ - Is the bet worth it?  Do the stakes justify the [Payoff](/thinking/Glossary#payoff)?
  - How can you maximise the stakes while minimising pay-off?  How long will it take for the pay-off to be worthwhile?
  - Are you making a long bet, or lots of small, short bets?  You can reduce the overall stakes by splitting work up and doing the riskiest part first.
 
@@ -149,4 +149,4 @@ But software isn't like this.  Largely, we aren't building the exact same thing
 
 What if you _are_ building the same cookie-cutter things over-and-over?   Perhaps it's time to change the bet?   By using new tools or techniques you would increase the risk, but also the reward would be to learn something new.  Alternatively, _build the library_ that automates the drudge-work so you can re-focus on the areas of risk.
 
-[The Purpose Of The Development Team](Purpose-Development-Team.md) article expands this idea further: that everything we do in a development team is about managing a balance of risks across the portfolio of an entire team's efforts.  In the next article though, we'll zoom in more closely and see how we use risk when we make [Debugging Bets](Debugging-Bets.md). 
+[The Purpose Of The Development Team](Purpose-Development-Team) article expands this idea further: that everything we do in a development team is about managing a balance of risks across the portfolio of an entire team's efforts.  In the next article though, we'll zoom in more closely and see how we use risk when we make [Debugging Bets](Debugging-Bets). 

docs/bets/Debugging-Bets.md

@@ -14,15 +14,15 @@ tweet: yes
 
 # Debugging Bets
 
-In [The Purpose Of The Development Team](Purpose-Development-Team.md) we looked at how a development team is all about trying to shift the risk profile in favour of the business.  Perhaps by removing the risk of customers not having the features they want, or not signing up, or not learning about the product.
+In [The Purpose Of The Development Team](Purpose-Development-Team) we looked at how a development team is all about trying to shift the risk profile in favour of the business.  Perhaps by removing the risk of customers not having the features they want, or not signing up, or not learning about the product.
 
-Then, in [Coding Bets](Coding-Bets.md) we considered the same thing at task level. That is, in choosing to spend time on a given task we are staking our time to improve our risk position.  And, it’s definitely a bet, because sometimes, a piece of coding simply doesn’t end up working the way you want. 
+Then, in [Coding Bets](Coding-Bets) we considered the same thing at task level. That is, in choosing to spend time on a given task we are staking our time to improve our risk position.  And, it’s definitely a bet, because sometimes, a piece of coding simply doesn’t end up working the way you want. 
 
 ![Article Series](/img/generated/bets/debugging/bets.svg)
 
 Now, we’re going to consider the exact same thing again but from the point of view of debugging. I’ve been waiting a while to write this, because I’ve wanted a really interesting bug to come along to allow me to go over how you can apply risk to cracking it.  
 
-Luckily one came along today, giving me a chance to write it up and go over this.  If you've not looked at Risk-First articles before, you may want to review [Risk-First Diagrams Explained](/thinking/Risk-First-Diagrams.md), since there'll be lots of diagrams to demonstrate the bets I'm making.
+Luckily one came along today, giving me a chance to write it up and go over this.  If you've not looked at Risk-First articles before, you may want to review [Risk-First Diagrams Explained](/thinking/Risk-First-Diagrams), since there'll be lots of diagrams to demonstrate the bets I'm making.
 
 ## The Problem
 
@@ -126,7 +126,7 @@ Sadly, this meant that I’d actually had to test and rule out _all of the other
 
 ## Some Notes
 
-1.  I started by writing down all the things I knew, and all of my hypotheses.  Why?  Surely, time was short!  I did this _because_ time was short.  The reason was, by having all of the facts and hypotheses to hand I was setting up my [Internal Model](/thinking/Glossary.md#internal-model) of the problem, with which I could reason about the new information as I came across it.
+1.  I started by writing down all the things I knew, and all of my hypotheses.  Why?  Surely, time was short!  I did this _because_ time was short.  The reason was, by having all of the facts and hypotheses to hand I was setting up my [Internal Model](/thinking/Glossary#internal-model) of the problem, with which I could reason about the new information as I came across it.
 2.  I performed four tests, and ended up ruling out six different hypotheses.   That feels like good value-for-time.
 3.  In each case, I am trading _time_ to change the risk profile of the problem.  By reducing to zero the likelihood of some risks, I am increasing the likelihood of those left.  So a good test would:
  - a.  Bisect probability space 50/50.  That way the information is maximised.