Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development



Start Here


Home
Contributing
Quick Summary
A Simple Scenario
The Risk Landscape

Discuss


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

Blog


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

Publications



Click Here For Details


Under Construction

Coding Bets

When you start an assignment or a piece of development, how sure are you that it will pay off? Often when we do some work on a software project, we’re asked “How Long Will It Take?” This is essentially trying to establish what the Stakes of the bet are. However, it’s also worth considering What the Pay Off will be.

For example:

Refactoring: The Technical Debt Bet

Making our codebase easier to reason about is worth the outlay of time

Technical Debt is excess complexity in your code. The bet here is that you can trade some time on the schedule to move to a place of lower complexity risk. It looks like this:

Stake: Schedule Risk
PayOff: Reduced Complexity Risk (making us more agile in the future)

To reduce technical debt there usually has to be some simplifying realisation:

“We don’t need this extra parameter to this function” “Class A and Class B are actually different implementations of the same functionality” “We can encapsulate more behaviour by introducing the command pattern”.

When it goes right, the codebase is easier to think about. When it goes wrong, either the complexity risk improvement is less than you hoped, or it takes longer to achieve, or the complexity returns in some other way, or it just doesn’t work at all, and you’re back to where you started from with the loss of time.

“Project speed is a function of codebase complexity and available talent”.

Spike Solutions: The New Technology Bet

A New Technology is a better fit for our problem than the one we’re currently using.

Quite often, someone will suggest using a new technology to either replace a poorly-performing existing technology, homegrown solution or gap in the functionality. But will the new technology fit? The answer is to try to “prove” the bet as quickly as possible using a “Spike Solution”.

Stake: Schedule Risk, Complexity Risk PayOff: Reduced Feature Fit Risk

“Let’s replace all our uses of java.util.Date with DateTime, as it’s less buggy”. “Let’s use ElasticSearch for searching instead of SQL Statements” “Let’s use JSON here instead of XML”.

This can go right in the following ways:

But it can go wrong in the following ways:

Reduce the stakes by:

New Feature Bets

This new feature may be exactly what our users are looking for

Sometimes it’s impossible to know exactly how the user base will feel about a new feature without building it. So, build the feature, and test it with a trial population.

Stake: Schedule Risk, Complexity Risk, Conceptual Integrity Risk PayOff: Feature Fit Risk

“We need to provide an export-to-Excel function, as our competitors have one” “Users need to be able to customize the workflow, otherwise they’ll go elsewhere” “We need a global search because people spend too much time menu-diving”

Outcomes:

Reduce the stakes by:

MVP: The New Market Bet

Building a Minimum Viable Product proves you can, but also proves the market

The idea of a Minimum Viable Product is to make a bet that a market exists for a certain product, and that there’s money to be made from it.

Stake: Funding Risk Payoff: Market Risk

“People will use the search engine and we can monetize it with advertising”. “People will buy pet food online” “Bots are the future: let’s write one for the insurance business”

Reduce the stakes by:

Conclusion

This was just a few examples, but this idea is generally applicable. Look at the next piece of code you’re about to write:

How can you maximize the stakes while minimizing 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? (Split work up, then do the riskiest part first)

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