Case Studies

The following analyzes some notable statements made by Juan, and uncovers non-obvious, hidden, and/or manipulative assumptions and presuppositions behind Juan’s statements. The main task here is not to analyze everything Juan ever said in the past, but to show the process of applying critical thinking.

False Expertise

I have been asked countless times about books to learn how design and make a modern game engine (like Unity, Unreal or Godot). I really have no idea what to recommend. I don’t have much free time (can’t promise anything), but would anyone be interested if I eventually write one?

Juan says that he has been asked countless times and assumes that he is considered an expert in this field or has substantial knowledge about how modern game engines work, which may suggest false expertise. By stating that he has been asked countless times about recommended books, he is seeking validation. He may be using this tactic to build credibility and imply that his knowledge is in demand.

He mentions that he doesn’t have much free time, implying that he might not be able to fulfill the request. However, this can also be seen as a manipulative tactic to create a sense of scarcity. By suggesting that he might not have enough time, he may be trying to increase the perceived value of his potential book or the work that he does in Godot.

Juan plays on the fear of missing out (FOMO) and encourages people to express interest, regardless of whether he intends to write the book or not. Juan does not provide any details about what the book would cover or how it would be delivered. It’s possible that he is using this vagueness to generate curiosity and interest among potential followers. Furthermore, Juan may not be inclined to recommend books to read because he doesn’t want to promote other works, because this could potentially lead Godot followers to discover alternatives that better align with their needs, causing them to abandon Godot.

At the same time, phrases like “I really have no idea what to recommend” and “can’t promise anything” can be seen as false humility. He may be downplaying his expertise or intentions to appear more relatable and garner sympathy from the audience, who are often students.

He mentions Unity, Unreal, and Godot in the same line. He indirectly implies that those engines can be compared on the same level, which creates a false expectation (read Misleading Competition below). Additionally, he implies that his book or Godot would be equally valuable or essential to aspiring game developers in the game industry as a whole.

Misleading Competition

Before analyzing the following statements, recall what Juan said that Godot does not compete with Unity or Unreal, see Competition chapter, which is worth repeating here:

Friendly reminder that Godot does not compete with Unity or Unreal.

Here are Juan’s statements that we’re going to analyze. Context: Juan shows statistics of various engines being used for game jams: 59% for Unity, 19% for Godot, 5% for GameMaker, and the rest is other engines:

I think leaving aside the competition debate (which quite frankly, despite my position that it’s not, its just all subjective rant), I hope game developers realize that at this point, if not for Godot, in 10 years Unity would have become the Photoshop of game development.

Godot’s existence is presented as the sole factor which allegedly prevents Unity from becoming dominant. The statement “if not for Godot, in 10 years Unity would have become the Photoshop of game development” is a speculative claim lacking concrete evidence. It assumes that Unity’s growth would lead to negative consequences akin to the dominance of Photoshop in image editing. However, the claim relies on a fallacious analogy since it fails to provide any rationale or data, and whether the dominance of Photoshop has any negative consequences can also be questioned in a similar manner. Additionally, game development attracts various branches of computer science, making it a complex and diverse field, and thus there may exist other factors preventing Unity’s dominance.

Juan presents a false dichotomy by assuming that Unity’s dominance would be universally undesirable for game developers, without considering the possibility that developers actively choose Unity due to its features and capabilities. This oversimplified view creates a false dilemma, where the only two options presented are Unity’s dominance with negative consequences or Godot’s existence preventing a supposed monopoly.

While Juan presents statistics of engine usage for game jams, he uses this data to support a sweeping generalization about the future of Godot in the entire game development industry. Game jams represent a specific context and may not accurately reflect long-term trends in game development industry, making inattentive followers of Godot falsely believe Godot’s adoption by the industry as a whole.

Juan dismisses any potential competition debate as “subjective rant” suggesting that any opposing views about the engines’ merits are not worth considering, that discussing drawbacks of different game engines are unimportant or irrelevant. This framing attempts to marginalize other perspectives and makes it appear as though only Juan’s opinion is valid, reinforcing his authority.

The statements describe how Juan’s communication subtly manipulates game developers’ perceptions and decisions as well. He sends a hidden subconscious message that implies game developers lack agency in shaping the future of game development and must support Godot to “reclaim control” over the industry. This overlooks the role of developers in considering, evaluating, and choosing from various alternatives, including the possibility of building their own specific solutions.

Juan’s statement exhibits a strong bias in favor of Godot, positioning it as a savior preventing a negative outcome, and downplays the potential for other game development engines to offer viable alternatives. This bias may impact objectivity when evaluating the potential trajectories of game development engines, as it influences developers’ perspectives and decision-making processes.

Blind Pragmatism

I always believed that your worst enemy as a software architect is the belief that you add a feature because “you or somebody will probably need it in the future”. Even if it can happen, my experience was always that the more pragmatic you can get with problem solving, the better (and far more maintainable) the code produced. I strongly believe that future proofing is a trap, but realize that its not easy to get into a pragmatic mindset.

Juan’s experience and beliefs to hold universal relevance for all software architects constitutes an extremely one-sided perspective. Such assertions disregard the possibility that projects may necessitate varied approaches to future-proofing. Generalization of personal experiences is perilous, as the Juan’s individual encounters are not representative of all scenarios. Such an extrapolation leads to biases, discounting other critical factors.

The dismissal of future-proofing, or rather, the ability to meet future expectations, as unnecessary and counterproductive, demonstrates a myopic viewpoint. It fails to recognize the potential benefits of thoughtful consideration and planning for forthcoming needs. While over-engineering can be wasteful, it is essential to acknowledge the importance of striking a balance and embracing the advantages of foresight.

A false dichotomy is presented by Juan, artificially pitting future-proofing against pragmatic problem-solving, as if these two crucial aspects of software development are mutually exclusive. This fallacious stance overlooks the potential for synergistic integration, wherein a blend of both can yield optimal results.

Juan demonstrates and advocates a fixed mindset, prioritizing blind pragmatism to the detriment of considering future needs. This rigid mindset inevitably inhibits growth and learning, hindering software architects from evolving their approaches and benefiting from novel techniques.

The oversimplification of maintainability perpetuates the notion that all future-proofing endeavors inevitably introduce complexity. In reality, some prudent design decisions can improve maintainability in the long run.

By overstating immediate pragmatism over future-proofing, Juan’s statements neglect the potential accumulation of technical debt, which can exacerbate codebase maintenance and extensibility over time. The emphasis on short-term benefits comes at the expense of disregarding the significance of aligning architectural decisions with the long-term objectives and vision of the project. Neglecting future-proofing undermines adaptability, hindering the project’s ability to embrace changing requirements and advancements in technology, leaving it vulnerable to obsolescence.

Furthermore, the assertive tone of Juan’s statements may inadvertently reinforce groupthink, stifling healthy debates and critical thinking among fellow software architects. Encouraging a diversity of design philosophies is crucial for fostering innovation and growth within the community.

Overall, Juan’s statements can be interpreted as excuse-making. He finds himself constantly needing to rationalize his carelessness under the guise of pragmatism.