Wordle as a Metaphor for the Software Development Process

We at Revelry have a #wordelry channel in Slack where we share our Wordle scores and commiserate about unlucky guesses. It’s a great way to goof off and appreciate the talents of our colleagues, and I hope we keep it up until all the words are used up.

When I first heard about Wordle, it struck me that the game is very similar to Mastermind⁽¹⁾, with five letters replacing the four colored pegs. In classic nerd fashion, I’m familiar with Mastermind more as a mathematical puzzle⁽²⁾ than a mildly psychological guessing game. In Mastermind, you can try to get into your opponent’s head and figure out what colors they’ve chosen, but the sure bet is to choose your “guesses” such that each gives you as much information as possible, reducing the number of remaining possibilities. I find that Wordle is a lot more fun than Mastermind, since words have meaning and evoke their own associations and trains of thought, but ultimately they’re similar in that you need to choose your guesses to narrow the possibilities until you land on the right word.

It turns out that building quality software that people want to use also requires us to iterate and sequence our work in such a way that we gain more and more information about the problem as those iterations progress. Some observations, at the risk of stretching the analogy too far:

• Waterfall⁽³⁾ is akin to thinking you’ll be lucky or smart enough to figure out the Wordle answer on the first try: If your requirements are exhaustive enough, your specifications detailed enough, your engineers ninja-y enough, and your QA process picky enough, you can’t help but deliver perfection on “launch day,” right?
• Iterating more quickly is like increasing the number of guesses you get, giving you lots of opportunities to be wrong and learn from your successes and misses. Classic Wordle allows 6 guesses, but a much harder variation, Quordle⁽⁴⁾, allows 9 to compensate for the difficulty. Building useful software is never easy, so we like to work in short 1-week sprints to maximize our chances.
• Regardless of iteration speed, building a product without showing it to real users is like writing down all your Wordle guesses ahead of time and just typing them in no matter where the black / yellow / green squares pop up. You may eventually guess the right word, but you’re really not helping your odds!
• It pays to deliberately sequence work in ways that will produce lots of information and reduce uncertainty early on. Savvy Wordle players have discovered that some words are better to start with than others⁽⁵⁾, because they yield a lot of information, even if they don’t share a lot of letters with the answer. Some Quordle players have even found that it’s useful to use up their first few guesses on words that span most of the alphabet⁽⁶⁾. We can do this when planning our sprints too: We can prioritize tasks with larger unknowns over straight-forward ones. We can figure out the quickest way to get an MVP in front of users so we can start testing and gathering feedback. And we should, because everything we learn in a particular sprint pays dividends in subsequent weeks.
• One of the things that makes Wordle so much fun is that everybody gets the same puzzle every day, so there’s a camaraderie and feeling of belonging that develops among players. We see something similar in our project teams, and that includes our partners since they participate directly in the process. We’re all rowing in the same direction, tackling the same set of problems, and getting to know and trust one another as we go.

A couple of my colleagues had some thought-provoking ideas to share as well. Quinn pointed out that sprint retro where we assess our progress

“The Wordle grid is like a retro, a breakdown of what went well (green squares,) what didn’t go well (black squares,) and what could have gone better (yellow squares).”

And Thomas turned the whole thing on its head. (Of course he did.)

“Wordle is a puzzle that presumably people want to have fun trying to solve on their own. Their goal is to see how quickly and elegantly they can solve the problem, and then share their efficiency and success with others. If instead the pure goal was to always solve the problem as quickly and efficiently as possible, then everyone would begin by asking whether anyone already has the solution, and utilize that information as their first guess. I realize how silly this sounds, but when we are building software, how often do we get caught up in our own cave working out a new elegant solution when our peers might have a shortcut they could share, which would enable all of us to spend more time working on problems without a shared solution?”

Have Wordle thoughts of your own? Hit us up in the comments!

Footnotes

1. https://en.wikipedia.org/wiki/Mastermind_(board_game)
2. https://www.cs.uni.edu/~wallingf/teaching/cs3530/resources/knuth-mastermind.pdf
3. https://en.wikipedia.org/wiki/Waterfall_model
4. https://www.quordle.com/
5. https://www.inverse.com/culture/wordle-top-3-start-words
6. https://news.ycombinator.com/item?id=30376706