“Poker, in contrast, is a game of incomplete information. It is a game of decision-making under conditions of uncertainty over time. Valuable information remains hidden. There is also an element of luck in any outcome. You could make the best possible decision at every point and still lose the hand, because you don’t know what new cards will be dealt and revealed. Once the game is finished and you try to learn from the results” Annie Duke

Annie Duke’s book Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts talks about thinking not in right and wrong but in probabilities. In software development, ideas, designs and code having strengths and weaknesses, not being right or wrong.

Software is like poker, not chess. Poker like software development, you decide with incomplete information.

Software development like poker involves luck, not just skill, where correct decisions and good software development can cause late or failed projects. The result of the project is not linked to the performance of the software development team.

Like poker, money is lost when things don’t turn out as we hoped.

Chess and poker

Life doesn’t look like that. It looks more like poker, where all that uncertainty gives us the room to deceive ourselves and misinterpret the data. Poker gives us the leeway to make mistakes that we never spot because we win the hand anyway and so don’t go looking for them. Annie Duke

Software development is a game of incomplete information, where people deceive themselves the software is less complex.

We create software without fully understanding all the requirements or how the separate parts fit together.

Most people on projects have an incorrect vision of how the software should work, which evolves during the project. You end up with software at the end, no one predicted at the beginning.

Chess has all the information upfront, poker is a game of incomplete information and luck. An amateur can beat the best poker player in the world in some hands but loses most of the times

With chess the best player would destroy the amateur every time. People don’t lose chess matches because of luck, they lose through poor play.

If software development was like this, a good software development team would then never be late or work on a failed project.

Any experienced developer will tell you, software development is not like chess.

Incomplete information

Software is creative. We create software based on requirements. There are too many requirements and too much interrelated complexity to get all these requirements upfront.

A simple way to think of complexity is the number of connections between functionality/requirements.

We simplify and split up software to enable understanding and to allow multiple development teams to create software. It takes too long to think through all the requirements and create a model of the software. It’s quicker and more effective to get 70 percent of the requirements, build the software and get feedback on what’s missing.

We start with incomplete requirements and discover complexity and additional requirements as we go. This is agile development and the downsides are broken plains, emerging complexity and technical debt.

For a software project to be delivered to the initial plan, you need luck or for the project to be small and the number of missing requirements to be low.

Like poker, luck plays a big part in software development.

Luck on software projects are

• Good developers
• Good lead developers and senior roles
• Few missing requirements
• Not many mistakes
• A lack of politics
• Effective decision making
• Effective IT
• Key people not leaving the project
• Functionality not deprecated
• Licencing doesn’t change drastically
• Architecture works under scale
• Engaged SMEs
• Technical disasters are not disruptive

The bigger the project, the more requirements, the more people and the more time increases the likelihood of problems.

Time, people and number of requirements add complexity and the probability the plan will be disrupted. The skill level of senior people increases with an increase in complexity, communication and collaboration.

Time pressure on software projects are the worst conditions for decision making and creating software. Rushed decision and rushed software are low quality and increased chance of short cuts. This encourages short term thinking and solutions which creates long term problems.

Today’s solutions create tomorrow’s problems.

Experienced, strong, talented developers, architects will try to resist these pressures but it’s reliant on leadership listening and following their lead.

Late or failed

Software projects are late or fail, even with the development team creating great software and doing everything right.

It’s likely the initial estimate, plan and design was made using incomplete or wrong requirements.

The level of incompleteness of the requirements is luck. Decisions can be correct, leadership is good, development outstanding but you cant beat an underestimated plan.

Most software projects aren't late, they are under estimated because of incomplete requirements. Extending a project plan to develop missing requirements is not late project delivery, it’s creating missing requirements.

Conclusion

Software development is done in a changing environment with incomplete information and done at speed (due to cost). It’s almost inevitable the initial plan will be wrong and underestimated because of missing requirements.

It shouldn't be a surprise, but often is. The time spent creating plans gives people an illusion of control that doesn’t exist. Projects that are delivered to the plan rely on luck that the missing requirements were few or not substantial.

The result of software projects isn’t related to the quality of decisions, skill levels and execution. Everyone on the project can do the right things well and quickly, but still be on a project that is late.

The best software developers and software development teams can lose even while creating great software. Software development uses incomplete information and software plans need luck.

None of this should be a surprise because for the past 60 years software projects have been consistently late. It just seems sales people and customers forget this or assume their project will be different. It won’t be, unless you are lucky.