In this episode, we create the Result type and refactor the Flow to accommodate scoring at the end of the Quiz game.

We spike some ideas on how to score the game and how to design the game models. We discuss about upsides and downsides of rigid types vs flexible types. We show different approaches to make your code more flexible and demonstrate that even with abstract types like protocols, we can create rigid designs that can impede us from maintaining a fast pace throughout the development cycle.

Moreover, we decide to go for the simple solution of Dictionaries and Arrays to represent our data structures, while using generic types for Questions and Answers. This option gives us a lot of flexibility, allowing us to maintain a fast pace and carry on with the development, while knowing that we can change our minds and refactor that decision easily.

Our goal is to keep our options open and move fast, while improving our design at every iteration. To achieve this we need a flexible design and good tests, which we’ve been very disciplined about since the first episode.

After 11 tomatoes, we created our first model type (Result), since we now have a better understanding of the domain. Premature decisions involving the domain can be harmful since the cost of changing things later can be very high, and it will most probably increase as the codebase grows (as more and more modules depend on those uninformed decisions, it becomes harder to fix these mistakes).

Having gathered enough information, we enable ourselves to make these engineering decisions, reducing the risk of wrong assumptions that can cost time and money. This same principle also enables projects to welcome changes, which is key for agile software development.

Subscribe now to our Youtube channel and catch free new episodes every week and follow along the project's progress on GitHub.