Code Kata: the card game of war

The card game of war is a very old, but still popular game. I used to play it when I was a child. The game is very suitable for small kids, because it has simple rules and the players don't need to make any decisions - it's enough to follow the rules. In this article, we will try to go through the process of modeling the game of war as a computer program. And as we will see later, the modeling may have some very practical uses. Let's start.

The game is usually played with 24 cards of four colors. The cards are as follows, next to each card there is a single letter that will represent the card for us.

• Ace - A
• King - K
• Queen - Q
• Jack - J
• 10 - T
• 9 - N

The colors do not matter in the basic version of the game. The 24 cards are distributed randomly between two players. Each player starts with 12 cards. The player who loses all the cards loses the game. Main steps of the game will be executed by the function:

nextMove (cardsA, cardsB)

Requirements discovery

Requirements have a long history in software industry. We all have heard or read terms like: requirements definition, requirements management, requirements decomposition... tons of books, trainings and requirements themselves have been created for software all over the world.

Today, some of us may still have traditional requirements as a base of what we develop, some of us have just User Stories and work off of that. But throughout this article, I will use the word requirements to mean all of that input: traditional requirements, User Stories and whatever else form of "that-which-is-needed" we may have.

Traditional way of thinking about how requirements are created is that they are defined. That is, a clever person sits down and writes them down. In this article, I will try to make a point that they are not that much defined as discovered.

In software endeavours where the requirements are expected to be defined upfront, the person or the people who define them inevitably miss the factors that influence the way requirements are defined. There is no way to avoid this it is true no matter how knowledgeable and experienced requiremens author(s) are. Conversely, by refraining oneself from going too far with definition, the authors get a chance of opening their minds to factors that help them discover that which they have possibly never conceived otherwise.

Factors that help us discover requirements:

Direct feedback from users or stakeholders seeing the thing on demos, tradeshows, etc. This may be unfinished, unreleased work shown to existing or potential users, people funding the work and other stakeholders. They get a chance of influencing the direction for the product or its features before they will get to use it.

Direct feedback from users using the thing. This may be partial, staged roll-out of a bigger feature, provding basic functionality and then iteratively enhanced using that feedback. Check out the Walking Skeleton, if you have not done already. This feedback can be gathered directly or we can try to encourage the users to fill in surveys (good luck!) or use Google Analytics to discover behaviors and patterns.

Ideas from Sprint reviews. Sprint reviews are fantastic opportunity to look together at was done, exchange opinions and decide on the next steps for the feature. A good review may sometime trigger nice additions to what is being developed, but it can also result in the decision to change the direction more strongly, or to abandon something previously defined or developed.

Technical factors such as the contents of data being processed or displayed, existing code, existing UI/UX design or technical limitations can also fuel requirements discovery. This relies on the ability of requirements author to engage into a technical discussion with the team and their willingness to listen and take that kind of input into account. Yes, I mean it - if being a PO (or similar role) you developed the thinking that you can get away with just "defining The What" with no interest in The How, don't hope for big successes with the team.

Aim of consistency can also fuel requirements discovery by remind us how the different features in terms of user experience, UI or user-perceived logic should feel like one, consistent product, rather than like a bunch of random things developed by different teams.

Similarly, aim of purpose can remind us the intent for our product. Even as the feature set grows, the "one tool for everything" approach never pays off in the long run.

And last but not least, the Proof of Concept (or Spike) activity can shed light on what we can or cannot do and strongly influece the requirements at an initial stage.

To sum it up, we should open our heads to factors described above, and any other that we can spot in our work. We need to accept the fact that we are not able to do a good "definition" job sitting at the desk and staring at computer screen. Instead, go discover what's waiting out there. Then work on the definition for a while and then go discover again. This is how great features emerge.