Deep Management #4: Aristotle Ruminates on Game Dev Part II

Even the blind can sculpt wonders, but it is easier when one can see.

Aristotle’s middle way teaches us to discern differences at higher resolutions. This clarity acts as one of several core pillars that upholds our productivity as entrepreneurial game developers. Without it, we will rely even more on chance.

In our previous article, we described Aristotle’s notion of ultimate and subordinate goods, as expressed through his lectures in Nicomachean Ethics. For all that we do, we should determine whether it offers inherent customer value (and thus is an an ultimate good), or whether it is a means to an end (a subordinate good). For subordinate goods, we must determine the “right” amount of effort. Too little starves the eventual ultimate good. Too much wastes resources that could be better spent elsewhere.

Here in Part II, we will answer that question of the “right” amount with Aristotle’s middle way (also known as the Golden Mean). Aristotle posed this within the context of ethics, to teach us how to live the best life. We’ll be applying it to game development. This is an art that requires practice. For the beginner, inexperience blurs challenges into an undifferentiated mass. With experience can arise wisdom — although only if we critique ourselves properly. That, in turn, allows us to unravel our problems and apply the correct force to their resolutions. When we understand the relationship of goods to each other, we know where to spend our effort to maximize the value we produce for our customers.

Of course, this isn’t always difficult. For some subordinate goods, the solution is obvious even to the neophyte. In this article, we address the harder cases.

For ethical goods, Aristotle stated that two extremes exist around the proper solution. While the right path can be found by the wise, even the untutored can locate the extremes. He terms these poles the defect and the excess of the good. We can characterize the defect as a “rejection” for all cases of a problem. Excess, then, corresponds to an “acceptance” for all. Sometimes, expertise requires knowing the proper amount of something to apply, for example a cook knowing the right amount of coriander for a dish; we can map that into the accept/reject model by defining the amounts as inequalities that form sets of numbers that we accept/reject.

Given the framing above, it is easy to understand what we mean by wisdom. The beginner can trivially choose given the nature of the poles, as that requires no capacity to discern anything. They either always say yes or always no, to all situations that arise. As the beginner learns and grows experienced, they develop an interpretative structure that differentiates cases with greater precision and accuracy. The master perfectly categorizes all cases (note, even with probabilistic outcomes this makes sense, as we maximize the expected return, thus aligning it with the EM algorithm from machine learning).

To further this argument, we’ll start with two ethical examples used by Aristotle: generosity and bravery.

To the Ancient Greeks, to share good fortune was a virtue. The individual deficient in generosity would be termed mean. The mean individual hoards their wealth and possessions, without fostering social good. They needn’t be risk averse; they will engage their resources when they expect on average to grow their wealth. Those who possess an excess of generosity we term the prodigal. They spend money without consideration of societal impact or maintenance of wealth. They throw profligate parties for all comers; they fund any artist, entrepreneur, or innovator who asks for money, regardless of merit; they purchase transient goods and never invest. Using our model, the mean individual rejects any action that expends resources for anyone’s benefit other than their own (some even refuse to spend for themselves!). The prodigal accepts any request for resources without critical evaluation. In between these two, we find the liberal. This person spends when opportunities generate an appropriate benefit to society, but otherwise conserves and maintains their fortune. They should not, however, maintain too much wealth, as that is its own form of waste.

Next, we consider the brave. Here, the defect would be cowardice, and the excess would be brashness. The complete coward when faced with danger always flees, hides, or cowers. The brash person, meanwhile, does not consider their limitations and always advances, regardless of the likely outcome. Sometimes, the wise choice is to retreat; sometimes, it is to advance. The brave evaluate the situation and acts appropriately. If the expected outcome does not exceed some threshold of merit, then the brave retreat. Otherwise, they move forward. Whether one feels fear or not is irrelevant. The brave feel fear, but allow it only to inform their actions, not to dictate them. Through wisdom and experience, the brave learn to differentiate between scenarios, and thus live the best life. Of course, the brave as opposed to the brash also create back-up plans.

Game development offers many such topics. Consider crunch. For the deficit, imagine those who don’t work many hours. For the excess, we have those who consistently run hundred-hour weeks or more. Some famous individuals have suggested this is necessary to succeed in start-ups! For example, Bill Gates and Elon Musk. Having worked in heavy crunch environments for over a decade, we question that. It’s easy to fetishize past sacrifices, rather than consider the opportunity costs they imposed.

Many arguments for and against crunch can be made (we cover this more in Deep Management), but let us consider the impact on our problem-solving and creative abilities. Research has shown the physical and mental impacts of stress and exhaustion upon us. We know that stress causes us to enumerate fewer branches for decisions, and that the generated branches tend towards more conservative options (without us being aware that this has occurred). On the savanna, this would have been useful when one noticed a lion in the bushes and needed to make an on-the-spot decision — fast over good. In innovative fields, however, it is the creative branches that offer disproportionate rewards. Stress prunes away the most desirable fruit. It also generates tunnel vision. Many pressured individuals fixate and consider only local consequences to fixes. Tired engineers receive bug reports and resolve the symptom, suppressing the problem, but not addressing the root cause. This rots the codebase and causes hydra heads to pop up elsewhere. Further, when our employees notice issues that they don’t personally own, stress inclines them to rely more on the hierarchy — that someone else knows about the fault and will fix it. Even problems that are obvious can go unfixed due to this, as everyone assumes that someone else will take responsibility. For anyone who’s wondered how blatant faults didn’t get resolved before launch, this is a common root cause. This can also result in failures to recognize opportunities.

In short, hard crunches leave us less agile, less creative, less rational, and less cooperative with our peers. Some will note that pushes can drive engagement! Up to a point, this is true, but go beyond that, and it falls apart.

Another conceptual problem many experience around the necessity of crunch is this: they consider only the current position, and not how they got into it. Trapped with immovable deadlines and harsh competition, they find no rational options remain. Once our conditions corner us this way, it can be a choice between cutting the project or burning the team and hoping. Sometimes we must pursue hope, although we should recognize that it exists outside rationality, due to its basis in magic, miracles, and faith (almost every game company has some term for this Magic — a cult centered around post-rational will).

We need to remember that a chain of decisions led us to the absurd, not inevitability. We chose to leap into the piranha-infested river, rather than seek customers elsewhere, perhaps with a more creative offering. In fact, once we get in the habit of crunch, it can be harder to perceive those alternatives.

Apex Legends and Fortnite pose an imperfect example of this. Fortnite quickly copied Apex’s key features, while Apex has so far been unable to match content delivery. In fact, Respawn Entertainment decided instead to conserve the health of their team and maintain future optionality. Epic Games has far more staff on Fortnite than Respawn has on Apex, so unless Apex changes the dynamic of their competition, attrition favors Epic. It was not random, however, that Apex ended up in competition with Fortnite in this way. This is similar to the classic problem of challenging a dominant market leader with a sustaining innovation versus a disruptive one. We max the difficulty by doing so. We then find ourselves either forced to cede a substantial part of the field or caught up in an uphill struggle. It was a choice to end up in this position. The story of Apex and Fortnite could still turn in many ways, so we shall see — it could also be that Respawn finds their smaller cut of the pie more than adequate.

As we work and choose the challenges we take on, we must consider whether the value of a particular push offsets the costs it imposes. Faced with service downtime, for example, there might be no other option. DevOps and SRE practices, however, answered this by asserting that we can change our patterns to make service downtime less likely and more recoverable. Sometimes we might trigger a small push to foster team cohesion (although this could be questioned as a practice). For each case that arises, we accept or reject the proposition, and whenever we accept -- if it was a forced push --  we then consider how we might have avoided it.

At this point, we must critique certain lines of Aristotle’s argument. These criticisms shade his meaning rather than refute it, but still bear discussion.

First, when we name our extremes using common words in language, we frame our perspective, often unintentionally. If we choose a forty-hour week as the defect, this anchors all subsequent discussion. Many suggest that the rigid work schedule of forty-hour weeks does not align with the requirements of innovation and knowledge-based development. They instead suggest less regimented patterns. By posing a forty-hour week as a pole, we suppress that line of inquiry.

Now, Aristotle does mention this. Sometimes a particular language lacks the exact signifiers to point at conceivable forms of meaning, thus complicating analysis. We can end up comparing two poles burdened with irrelevant baggage. We used the term brash when discussing the brave, for example, where brashness brings with it additional nuances of meaning.

Second, some problems ought to be solved at their extremes. Linear programming would be one such case.

Even in more complex problem spaces, while the extreme might not be optimal, it can be advisable to take an aggressive step to break us out of a local minimum.

Theory of Constraints would be one well-known approach that functions this way. This model assumes that a small set of constraints limits our maximization of a particular good. The core loop of this method works by identifying the most serious constraint, focusing effort on eliminating it, and then validating that nothing has been broken. This originated out of manufacturing environments, but it maps onto other domains with some tweaks. We discuss Theory of Constraints further in Deep Management, plus there is a rich literature online, as well as its original conceptualization in the business novels The Goal and Critical Chain. We do consider this an older modality, but it has influenced many modern approaches.

However, while I’ve posed this point as a criticism of Aristotle, it also aligns in a specific way.

Aristotle notes that we as cultures (including the culture of game development) tend to favor one polar extreme over the other. This often arises from societal norms, such as Confucian and Protestant work ethics. Because the accept/reject model of the extremes can be easily adopted, neophytes tend to seek out the poles first. Culture usually signals a preferred option. We assume that this preference indicates a more successful strategy — wisdom of the crowds. Thus, in game-development culture, the preferred extreme tends to be crunching. That is fair enough for a start. What we need to remember, however, is it is a starting point only. Through experimentation, empirical validation, and humility before the truth, we can improve our ability to distinguish the cases where we need to push hard versus those where we should recover and focus on more wide-ranging creative thinking.

Continuous self-introspection must become our habit. Take our meeting culture. Do we have too many? Are they too long? Too many attendees? What purpose do they serve? Sometimes it is necessary to think radically: set-based development came from Lean, and provides an alternative to a common type of meeting. This solution favors agility and late decision-making, but flips many assumptions.

Aristotle’s purpose in all of this was to teach us how to live a better life. This is true for us in game development as well. We want eudaimonia on the work floor — the ability to enjoy solving our customers’ problems while still sustaining a state of serene calmness and happiness.

John Bible
Twitter: @JohnJadeBible
Main Site: http://johnbiblebooks.com
Game Site: http://artofgeekery.com