Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development

Start Here

Quick Summary
A Simple Scenario
The Risk Landscape


Please star this project in GitHub to be invited to join the Risk First Organisation.


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019


Click Here For Details


Let’s go back to the model again, introduced in Meeting Reality.

Meeting Reality: reality is changed and so is your internal model.

As you can see, it’s an idealized Feedback Loop.

How fast should we go round this loop? The longer you leave your goal in mind, the longer it’ll be before you find out how it really stacks up against reality.

Testing your goals in mind against reality early and safely is how you’ll manage risk effectively, and to do this, you need to set up Feedback Loops. e.g.

.. and so on.

Time / Reality Trade-Off

This list is arranged so that at the top, we have the most visceral, most real feedback loop, but at the same time, the slowest.

At the bottom, a good IDE can inform you about errors in your Internal Model in real time, by way of highlighting compilation errors . So, this is the fastest loop, but it’s the most limited reality.

Imagine for a second that you had a special time-travelling machine. With it, you could make a change to your software, and get back a report from the future listing out all the issues people had faced using it over its lifetime, instantly.

That’d be neat, eh? If you did have this, would there be any point at all in a compiler? Probably not, right?

The whole reason we have tools like compilers is because they give us a short-cut way to get some limited experience of reality faster than would otherwise be possible. Because cadence is really important: the faster we test our ideas, the more quickly we’ll find out if they’re correct or not.

Development Cycle Time

Developers often ignore the fast feedback loops at the bottom of the list above because the ones nearer the top will do.

In the worst cases this means changing two lines of code, running the build script, deploying and then manually testing out a feature. And then repeating. Doing this over and over is a terrible waste of time because the feedback loop is so long and you get none of the benefit of a permanent suite of tests to run again in the future.

The Testing Pyramid hints at this truth:

The Testing Pyramid


You could take this section to mean that Continuous Delivery (CD) is always and everywhere a good idea. That’s not a bad take-away, but it’s clearly more nuanced than that.

Yes, CD will give you faster feedback loops, but even getting things into production is not the whole story: the feedback loop isn’t complete until people have used the code, and reported back to the development team.

Different actions have different feedback loops

The right answer is to use multiple feedback loops, as shown in the diagram above.

In the next section De-Risking we’re going to introduce a few more useful terms for thinking about risk.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.