What Happens After the Car Crashes?
Building games with my son taught me how kids learn to think past the first idea.
“Make a game where the car crashes!”
My stakeholder is three-and-a-half, and most of his feature requests involve similar levels of spectacle and poor specification. While the grand, dopamine-inducing storyline of crashing cars may be fully formed in his mind, his request contains almost no information that would help me realize it. What is the car doing before it crashes? Is crashing good or bad in this game? Does it affect points, or mean that it’s game over?
I spent twelve years in software, the last several writing and reviewing specs as an engineering leader. I came face-to-face with the realization that second-order-effect thinking is a learned skill, to put it mildly. And after all that time, building games with my son may be the most advanced crash course in it that I’ve ever had – from someone who can’t read the specifications.
Every request is an iceberg
Whether it’s one request from your three-year-old or from one of your top three customers, features rarely arrive fully specified. A few recent examples:
“Make a game where the car crashes!” – How does it crash? What’s it doing beforehand? What does a crash mean here: good, bad, a change in points, or is it game over? What does crashing look like, and what does it result in – a pile of debris? An intact but undriveable vehicle? A cloud of purple stars?
“You should play the game and collect items.” – What are the items? What happens when you collect one? What does collecting do for your game score (if there is one) or result?
“The game should unlock cars by driving more.” – What does “more” mean? Time? More distance? (He had a more precise answer, it turned out. He always does. He just doesn’t volunteer it, because inside his head the picture is already complete. Sound like anyone you’ve shipped for?)
None of these examples are bad feature requests. They’re normal requests, arriving incomplete from a mind working with different context.
Lest this sound like I’m dunking on a preschooler, I’m not immune from poor specification either. We built a dump-truck game – drive, dump dirt, repeat (a banger, ask anyone who’s three). I wanted celebratory feedback, so I typed: “Add a cheery status message that says ‘Dumped!’ over the truck when the dirt dumps out.”
Claude did exactly that. And “over the dump truck”, in literal interpretation, blocks any view of what the dump truck is doing. So at the precise moment of maximum dumping, a triumphant banner covered the only thing my son wanted to watch. The full context of the game’s main purpose (watching dirt get dumped) lived in my head and I neglected to provide that context in my prompt. Meltdown followed, because, three.
That’s the shape of most specification failures I saw professionally, too. A feature request describes the moment and often omits the state that follows. It stops one frame too early. It’s not just for building games, either, but carries into snack requests and even bedtime stories.
Shared context
At its core, specifications are just good communication. Until we get telepathy, we’re stuck having to use our voices and keyboards to do the incredibly difficult work of reconciling divergent worlds.
Every engineer has lived the grown-up version. One (of my many) battle stories: a system designed end-to-end on the assumption it would deploy to a long-running on-prem infrastructure – only to discover, late, that it was destined for a very short-lived execution running in AWS… Lambda. Nobody had “lied,” exactly. It had simply never been discovered that the devs and the stakeholders were operating on two complete and completely incompatible understandings. The toddler version costs a minutes-long meltdown over a missed dirt dump. The professional version costs a quarter (or two).
How to ask (a toddler, or anyone)
With both the three-year-old cohort and in professional experience, I’ve learned that the best clarifying questions are the same: they must be exceedingly simple and anchored to tangible things. “What do you see when the game starts?” works. “How do you win the game?” gets a blank stare. It’s similarly useful with adults to work out a simple list of end-states. (It’s stunning how often this seemingly-obvious step is omitted and how much money that omission costs.)
Abstract questions about goals and mechanics get similarly abstract answers. Concrete questions about things you can see and states you can achieve are much more successful at aligning expectations.
Teaching thinking
When I model good requirements gathering and specification for my son, I just call it “thinking things through.” It pays off in every aspect of our lives (though less often than I would like in the toddler treat negotiation department). As he grows older, his games are getting more advanced and his imaginative powers more detailed and precise. We’ve gone from 2D games with CSS sprites to Three.js-powered open worlds where rally cars drive around collecting treasures, and collecting enough of them unlocks more cars and more worlds to drive in. His spec.
If you want to help train your kid’s second-order-effect thinking, 12 Weeks of Tech Projects for Toddlers is the curriculum we use. It’s at buildwithyourkid.com .