"Star Fluxx" is a science-fiction-themed version of "Fluxx", a card game where the rules for playing cards as well as the conditions for winning are constantly changed through cards played by the players. When I heard the description of the game on the aforementioned episode of TableTop, it reminded me of software development projects. Changing business rules and requirements probably sounds familiar to you, too.
When you continuously develop new features and deploy new code to production frequently, quality must not be an afterthought. Today, the Agile style of software development is all about short and iterative sprints, but as a result quality can no longer be taken care of at the end. It has to be addressed throughout the software development process. Quality includes, but is not limited to, assuring that the code works correctly while ensuring that it can be changed with ease when the business rule it implements changes.
Imagine for a minute that you were given the task of implementing "Star Fluxx". What would be more natural than to implement each of the game's cards in a separate class (all of which share the same interface, of course)? The rules of the game, embodied in the real world by special cards, then become nothing more than objects. When the game starts, we simply create an object of the class that implements the basic rule of "draw one card, play one card". At the beginning of each turn, the game's main loop now simply asks the current rule object how many cards the current player has to draw and how many cards they have to play. Should a player play a rule-changing card, for instance the "draw two cards, play two cards" card, we can simply replace the current rule object with the new one.
Now imagine how hard this would be to implement without the advantages offered by object-oriented programming. If the game's rules were hard-coded – in the main loop, for instance – existing code may have to be changed when new rules are added to the game, because the rules are not encapsulated in an isolated unit of code.
A class is easy to unit test when it has one clear responsibility (such as implementing one business rule) and when its dependencies are explicit and minimal. Dependencies are explicit when they are pushed into an object by means of Dependency Injection and not pulled into the object by creating new instances of classes the object depends upon. Other forms of implicit dependencies include the interaction with the global state and the usage of static methods. A class that follows these design principles is loosely coupled and highly cohesive. These qualities are not only important for testability but also make it easier to adapt the class when the requirements change.
However, there is one caveat when using "Fluxx" as an analogy for software development: "Fluxx" is a competitive game where players play against each other. The analogy would be perfect if "Fluxx" were a cooperative game where all players collaborate to reach a common goal. Elder Sign and Pandemic, covered in other episodes of TableTop, are examples of such games.
Software development in general and quality assurance in particular have to be collaborative efforts in order to be successful. I think this is what James Whittaker means when he writes:
The only way a team can write quality software is when the entire team is responsible for quality. That means product managers, developers, testers ... everyone.