All projects need Chickens and Eggs
Below the video is the text version.
Building software requires chickens and eggs. The problem is: Which comes first, the chicken, or the egg? It works like this.
You have a programmer, talking to a designer.
The programmer says “Please give me the design the users need.”
The designer says “Please give me the technological limits we have.”
On both ends, the ask is reasonable. The programmer wants to know what users want, so they can build that. The designer wants to know what could be built, so they can design what is feasible to build.
If the programmer does not know the full design, they have a hard time building the architecture that needs to be built within the project’s time limit. If the designer does not know the full possibility space, then they have a hard time designing features that can be built within the project’s time limit.
The problem in-between the two people is…
Time
What can be done in the time available? There is always a limitation of time, no matter what is being built. Which causes one party to ask for a chicken, and the other to ask for an egg. But while the ask is reasonable, it causes major problems.
If the chicken is delivered first, by the programmer saying “Here is everything we could possibly do.”, it would take them a very long time to gather all that information, and the designer now has a very complex framework to work within, with no wiggle room.
On the other hand…
If the egg is delivered first, by the designer saying “Here is everything we could design.”, now the programmer has to figure out how on earth they are going to make all that design within the appropriate framework and time, with no wiggle room.
Neither the chicken or egg actually help the project.
So what can who do instead? The right way to concept up a project, is to do some…
Table Tennis
Both parties know the general direction they need to go in, but not the specifics. So one of them has to ask: “What about… this?”
For example, the programmer says that with the current API, it is easy to do a lot of UI work, but the server architecture is sadly a bit slow.
Now the designer has a little bit of their egg! UI is easy, server architecture is slow, alright, hmm… “What about this?”, and the designer may suggest a feature requiring a lot of UI, but some motion design as well.
The programmer can now say “Ah, I see what you mean”, as they have a little bit of their chicken. And so they again, make a suggestion, in this case about the implementation of the motion design. And so the knowledge of what can, and needs to be built, grows.
Sometimes, someone might give a suggestion for something that isn’t possible within the timeline of the project. In which case a good producer will stop them from over scoping.
Which means no chicken and egg growth at all. But that’s fine! That’s great actually. Because now there is a conversation about what can be built, how it can be built, and how it can help the customer, instead of everyone having to understand the entire chicken or egg at one time.
And so the table tennis continues back and forth…
Everyone iterating and learning about what is and isn’t possible…
Figuring out what needs to be built….
Gaining knowledge about the possibilities and time…
Until in the end…
We have a chicken, and an egg, at the same time.
Of course this also goes for programmers and artists. For artists and designers. For producers and designers. All of those can have table tennis conversations. But some of you, as independent developers, or unicorn developers, do both technology and design at the same time.
You, alone, will also go through this process of learning where you are going…
And then building, designing, iterating…
Growing the concept further and further…
And answering the questions of both technological and design aspects…
Until you have what you need.
But without a producer, it becomes very easy to overscope, so watch out for that.
The conversations you have with others, and with yourself, take time. But it is much better to have spent a little time having those discussions, rather than spending 6 months, a year, or even longer, building something that nobody ends up using. At the same time, it is also very important to have these chicken and egg conversations all the way at the start of a project. Once decisions have been made, you should stick by them as much as possible.
Creative Direction
It is fine to iterate and discover, especially from playtests that you should run continually and learn from. Iteration can be things like having a forest level, and the leaves are green, and then you decide later that the leaves are brown. Great. But, if there is suddenly a decision to make the level on the moon, and cut the entire forest, and then a few weeks later bring the forest back again, then whoever is making those decisions is not iterating properly. This really happens, and it is a large reason why games take so long to make nowadays.
I mention this as I keep seeing arguments for games taking long to be built due to hyper realistic expectations for art, or there simply being lots of art. What I don’t see is the actual most costly reason: Indecision.
Iteration is good, but the yearly rebuilding of entire characters, storylines, and levels, is the most expensive thing. Especially if folks keep asking for whole chickens, and whole eggs. The same goes for letting chickens and eggs infinitely grow in size. Directors have to give producers the power to tell folks to stop expanding scope. These are both problems of creative leadership, and if you have watched many GDC talks, or been a game developer, you will have seen this.
Whenever a game ships in record time, the director is shown to make, and keep, decisions. Whenever it goes over time, you eventually hear of constant changes. This also ties into the problem of copycats. Especially now with genAI.
When copycats of games appear really fast, folks wonder why all games can’t be made that fast. It’s because a copycat has no problem with indecision. All decisions are already made. There is no table tennis or iteration necessary. Game creation has always been 20% building, 80% iterating (That’s probably creative endeavors in general.), but it is really easy to get stuck infinitely reworking what is already fine. That work feels like progress, but it is not. And that’s a problem of creative direction.
So the table tennis of a conversation is great, as you cannot create either a whole chicken or a whole egg from scratch, but once the table tennis of conversation has happened, you stick with those decisions.
You understand the chicken and the egg. You cannot suddenly decide you are actually making a dragon. And a producer should make sure you don’t, while a director should make sure everyone understands the scope.
So next time someone asks for a chicken or an egg, suggest playing some table tennis instead.
Thank you
Thank you very much! You can subscribe to see more articles in the future, and follow me on LinkedIn, Bluesky and Mastodon, or even support me on Patreon
Thank you to Sander, Chris, Ben, and Nicole for their feedback and sanity checking!