On Gambling and Technical Debt

A heuristic approach to solving a complex problem is a practical method, not perfect in its solution, but good enough to solve the current problem with the intent of speeding up the nearly impossible, complex decision making that would otherwise be required for a perfect solution.

Applied incrementally to small chunks of problems within a complex system, accretive knowledge about the system is created (and value delivered along the way to the business or customer); feeding this knowledge back into improving the heuristic itself, continuously skewing the performance curve (value of success/failure over N events) further in our favor.

We need to start with good, previously proven heuristics with a performance curve skewed in our favor and take small enough incremental steps such that we never run out of rope while we also continuously deliver value, further increasing our run rate.

Think of gambling at the craps table with $100. First, you can create a heuristic/statistical model based on understanding of the physical reality of throwing dice; the goal is a performance curve skewed in our favor, even if ever so slightly. Keep in mind, this is a probabilistic curve – you know that on average you will win (or come out ahead), say, 51 out of 49 throws, but you never know with certainty that the next throw is a winning one. (Disclaimer: while I'm using craps as an example, this probability is used as an example and does not reflect the actual physical reality of the craps game!)

Similarly, we can think of any particular change we want to apply to a highly complex, messy, coupled software system as a probabilistic event with unknown outcome. Only after attempting change with a specific technique do we know whether that change will be successful or not, at which point we decide to bail and try a different technique (at the cost of time) or we succeed and deliver value.

Source: Nassim Taleb's Antifragility

Considering the above visualization of a non-linear convex performance curve (Gain/Loss curve, Reward curve), we can try to think of a “software change” as a random probabilistic event. As such, the theory suggests that we cannot focus on the quality of the event itself (planning/designing the perfect solution, which is nearly impossible to determine upfront) but rather should focus on creating as non-linear and convex of a performance function as possible. Process over outcomes.

Evolution is a convex function of stressors and errors – genetic mutations come at no cost and are retained only if they are an improvement. So are the ancestral heuristics and rules of thumbs embedded in society; formed like recipes by continuously taking the upper-bound of “what works” – Nassim Taleb

Back to the craps table with a $100 in your pocket, would you bet the entire $100 on your first game, or even $50, knowing that you (hypothetically) hold a 51-49 upper hand? NO! You would still also hold a very high 49% chance of losing on any given experiment, and once you lose that initial $100, you don't get to play again – game over, go home, you're dead (or bankrupt). But if you were to bet a smaller, proportionally adequate amount that allows you to build an event space sufficiently large enough for averaging, you are more likely to come out ahead after 10, 100, 1000 plays.

The beauty of applying well understood and proven refactor heuristics to software engineering of complex systems is that those experimental events are no longer statistically independent of each other as they are when playing craps, but build upon each other allowing us to continuously alter the heuristic, improving the performance (cost-reward) curve in our favor.

What can we take away?

1. Chose the right game to play using starting heuristics skewed in your favor. (Yes, you get to chose, in technology and business, which game to play and on which risk-reward curve to live. Focus on creating a convex risk-reward curve rather than on the perfect solution, plan, or outcomes)

2. Don't bet all your money on the first bet. (Need to make investments small enough that allow us to keep investing without running out of options, while continuously evolving a more heavily skewed risk-reward curve.)

3. Bet proportionately more as you accrue knowledge. (If our process creates a heavily skewed cost-reward curve, and we have enough of an investment reserve, we should continuously grow the size of our investment to avoid being disrupted by somebody else's Black Swan discovery.)

This discussion doesn't yet cover Nassim Taleb's concept of a Black Swan event, which may not be applicable to managing tech debt within complex software systems per se, but which further helps skew the reward curve in our favor and is one of the drivers behind fundamental, innovative product and business disruption.

This article was originally posted on Medium.

Comments

[Itan]

The key is to integrate these strategies into the core of your development process, making them non-negotiable rather than optional. It requires commitment from all levels of the team, from developers to project managers and stakeholders. Educating everyone involved about the long-term benefits of managing technical debt effectively can help. Remember, the goal is not to eliminate risk but to gamble smartly, ensuring that your bets on technical debt don't compromise the project's future. For those interested in exploring more about managing risks and strategic decision-making, visiting melbet.com/fa/bonus/rules/1st might offer some interesting parallels in the world of professional gambling. Just as in gambling, the right strategy can make all the difference