A couple years ago, I was an avid Texas Hold 'Em player. For about a year, I played 4 tables at a time online for a few hours a day, I read poker books, and I made enough money to pay my rent. (Because you're playing against other players rather than against a casino, it's actually possible to make money at poker.) Eventually it started feeling like a grind instead of a hobby, and I gave up on the game to spend more of my spare time on software-related pursuits.
These days I just play occasionally for fun, but I'm glad I put so much thought and energy into the game for a while. Hold 'em is a true meritocracy; you will only win in the long term if you are better than your opponents. There is no vagueness to the result. You either quickly learn to plug the holes in your game or you lose. Because it's a non-trivial undertaking but the results are so unavoidable, there are several life lessons that the game illustrates quite well.
Here are a few of my favorite lessons from hold 'em as they apply to risk management in software development projects:
These days I just play occasionally for fun, but I'm glad I put so much thought and energy into the game for a while. Hold 'em is a true meritocracy; you will only win in the long term if you are better than your opponents. There is no vagueness to the result. You either quickly learn to plug the holes in your game or you lose. Because it's a non-trivial undertaking but the results are so unavoidable, there are several life lessons that the game illustrates quite well.
Here are a few of my favorite lessons from hold 'em as they apply to risk management in software development projects:
Understand expected value, and use it!
Players who don't understand the concept of expected value don't generally do well at hold 'em (or any form of gambling, for that matter) in the long term. If you understand your chances of winning, the cost of losing, and the reward for winning, the decision of whether to call a bet or fold becomes purely mathematical. If you don't, the best you can do is guess. Often, you'll guess wrong.
Often project managers and sponsors usually don't know how much a project will really cost them or how much value they will gain from it. Even if cost & benefit projections are available or relatively easy to calculate, no one calculates the expected value.
I know of one company that began calculating the expected value (or ROI) of projects and realized they had signed a deal with a development cost ten times higher than they would get paid for it. Obviously projects like this have a negative expectation, but they get undertaken surprisingly often if no one checks the numbers.
The same analysis can (and should) be applied at a more granular level. It's old news that the majority of features in an average software product are rarely or never used. I have a suspicion that these features sneak into software products because no one bothers to think about their expected values.
One more thing: expected values aren't just for deciding whether to play a hand or not. You can (and should) also use them to decide whether to stay in a hand. We all know perfect project cost estimation is impossible, so continuously revisit your estimates once you have a few iterations under your belt. If the expected value of a project or feature changes, don't ignore that information! That brings us to lesson number 2:
Often project managers and sponsors usually don't know how much a project will really cost them or how much value they will gain from it. Even if cost & benefit projections are available or relatively easy to calculate, no one calculates the expected value.
I know of one company that began calculating the expected value (or ROI) of projects and realized they had signed a deal with a development cost ten times higher than they would get paid for it. Obviously projects like this have a negative expectation, but they get undertaken surprisingly often if no one checks the numbers.
The same analysis can (and should) be applied at a more granular level. It's old news that the majority of features in an average software product are rarely or never used. I have a suspicion that these features sneak into software products because no one bothers to think about their expected values.
One more thing: expected values aren't just for deciding whether to play a hand or not. You can (and should) also use them to decide whether to stay in a hand. We all know perfect project cost estimation is impossible, so continuously revisit your estimates once you have a few iterations under your belt. If the expected value of a project or feature changes, don't ignore that information! That brings us to lesson number 2:
Don't throw good money after bad.
The biggest mistake most players make is putting more money into a pot when they have very good reason to believe they are going to lose. Why would someone do this? They've crossed their threshold of pain. In other words, it's likely they've already lost $100, but there's some slim chance they haven't. The psychological difference between losing $100 and $200 is minimal, but the psychological difference between losing $100 and winning a few hundred is huge. Unfortunately, when you make decisions based on the emotional distance between different outcomes, rather than based on the statistical likelihood of those outcomes, you'll get yourself in trouble.
The same thing happens on software projects. Even when it is clear a project is a train wreck, if enough money has already gone into it, people will get really good at coming up with reasons to continue putting money into it. Don't be one of them. The fact that you made bad decisions is not a good reason to continue making bad decisions.
The same thing happens on software projects. Even when it is clear a project is a train wreck, if enough money has already gone into it, people will get really good at coming up with reasons to continue putting money into it. Don't be one of them. The fact that you made bad decisions is not a good reason to continue making bad decisions.
- - -
The interesting thing about these two lessons is that they aren't by any means earth-shattering; they're basic common sense. They basically boil down to this: only make decisions that make financial sense. After reading this article, you may find yourself thinking "Well, duh!"
It's tempting to dismiss the above lessons for that reason. We'd all like to think we are above irrational behavior, so we don't need to be reminded of such common-sense lessons. In poker at least, that's clearly not the case. The biggest challenge for would-be poker pros isn't knowing when to call, when to fold, when to raise; it's having the self-discipline to fold when you know you should. Optimism, pride, and desperate hope drive them to keep putting money into a pot they're unlikely to win.
I think the same thing happens in software development. Everyone realizes that they shouldn't pay twice as much to develop a product as they will be paid for it. The problem is that we don't always have to self-discipline to stop, measure both sides of the equation, and make the hard decisions based on the results.
It's tempting to dismiss the above lessons for that reason. We'd all like to think we are above irrational behavior, so we don't need to be reminded of such common-sense lessons. In poker at least, that's clearly not the case. The biggest challenge for would-be poker pros isn't knowing when to call, when to fold, when to raise; it's having the self-discipline to fold when you know you should. Optimism, pride, and desperate hope drive them to keep putting money into a pot they're unlikely to win.
I think the same thing happens in software development. Everyone realizes that they shouldn't pay twice as much to develop a product as they will be paid for it. The problem is that we don't always have to self-discipline to stop, measure both sides of the equation, and make the hard decisions based on the results.
