Mob Programming an Enigma Machine: A Coding Dojo Experiment

Last night, I went to a Coding Dojo meetup event on Meetup.com, Programming Dojo Utrecht meetup, hosted by Rentman! They advertised that we were going to do something called "mob programming" in a Dojo format. I had never tried mob programming before or a code Dojo in a meetup. I was curious about what was going to happen and how a whole group of people working on a single puzzle together would actually pan out. So, I joined up!

What followed was part story, part chaotic hackathon, and part scientific experiment in software engineering psychology.

Here are my notes from the trenches.

Phase 1: The Setup

This was the meetup's first event, and the organizers explained that in each session, we'd work through a "kata", a well-defined coding problem solved together using test-driven development (TDD), pair or mob programming, and a healthy dose of debate on design decisions.

After a brief introduction to the concept of mob programming, they revealed the night's problem: Recreating the Enigma machine using APIs.

There were about 20-25 people in attendance. After learning how a real Enigma machine works, the organizers broke the machine down into three different problems, effectively splitting us into three teams. For the final product to work, all these different sections had to integrate and communicate perfectly to spit out an encrypted (or decrypted) answer.

I was grouped into the team yellow, or as I called it "Rotor Housing" team, mainly because I couldn't remember the colors of the teams! Our job was to pass the key presses from the Green team to the Blue team, and then pass the result through the reflector logic, which did a one-to-one mapping of characters, and then output the resulting character.

Phase 2: The Rules of Engagement

There were six of us on our team, and we had to stick to the strict roles of mob programming at all times:

• The Driver: The person writing and typing the code.

• The Navigator: The person telling the driver exactly what to do.

• The Mob: The rest of the team, who get together, discuss the problem, and make the big design decisions to feed to the navigator.

We set a timer to switch roles every five minutes: the navigator became the new driver, the old driver rejoined the mob, and a mob member stepped up as the new navigator. This was a bit diffuclt to pay attention and so we only switch we noticed the timer was zero not when it actually hit zero!

For our very first rotation, we put the junior developer on our team in the driver's seat. It was a good start because we began very simply. The navigator told the driver how to set up the basic working environment and write the skeleton code.

Importantly, we weren't allowed to use AI, which everyone was happy about!

We chose Python because our junior developer only knew Python. The rest of us were perfectly fine with it since Python has great pseudo-code syntax and is incredibly easy to read. Interestingly, we noticed later that every single team independently came to the exact same architectural decision: we all decided to use Python and FastAPI to create an HTTP server to interface with the other teams.

Phase 3: Sticky Notes!

Here is where the experiment got truly interesting.

Our team was placed in a separate room. Even though we were supposed to interface with two other teams, the only way we were allowed to communicate with them was via sticky notes. We would write a message, hand it to a meetup organizer, and they would physically walk over to the other room, deliver the note, and eventually return with a sticky note reply.

Negotiating API contracts via handwritten sticky notes is quite chaotic. We quickly ran into the problem of simply not being able to read each other's handwriting in the rush of the moment.

We sent the other team a proposal for our server. They replied, "Hey, this is our server as well, this is what you guys can use." Luckily, we thought it looked good and stuck to it. Later, a team using our server sent a note saying, "Hey, we need a revision, we'd like it to be like this." Because negotiating on sticky notes is incredibly difficult, our response was basically, "Fine, we'll just do it."

Documenting a JSON structure on a tiny piece of paper is nearly impossible. You don't want to spend your whole time trying to write perfectly formatted text. So, our strategy pivoted: get the FastAPI server up and running as quickly as possible, expose it to the outside world using ngrok (which was provided as part of the meetup), and let FastAPI's auto-generated OpenAPI/Swagger docs do the talking.

Once they could see the Swagger page, they could start using it. However, the ngrok URLs were incredibly long. Initially, I put our URL in a GitHub project README and told the other team to go find our fork. That turned out to be too much of a task, and they sent a note back saying they couldn't find it. In the end, we just painfully wrote out the massive ngrok URL on a sticky note, told them to try it, and it miraculously worked.

Phase 4: Scientific Results

We only had about 75 minutes to actually work. In the end, our team managed to implement the API integration with a few last-minute bug fixes that required a single determined programmer to just finish it off, slightly breaking the mob rhythm. However, we completely ran out of time to implement the actual Enigma Reflector algorithm.

As I look back at the night, a few fascinating software engineering dynamics emerged:

1. Design Disconnect

While the driver and navigator were busy setting up the codebase, the mob was busy solving the puzzle. The mob wasn't actually telling the driver/navigator what to do; they were having a high-level design session. Because we were in such a time rush, we couldn't do a "design first, code later" approach. As a result, I completely missed the logic behind why we wrote the algorithm the way we did. During those crucial design decisions, I was either driving or navigating. The code was universally understood because everyone took a turn writing it, but the reasoning behind the code was lost on whoever was busy at the keyboard when the mob was discussing it.

2. The Specialization Trap

The core idea behind mob programming is that nobody hoards information; knowledge is shared. But given the strict time limit, we instinctively became specialized within our team without discussing it. People in the team started focusing on specific areas. Once the mob reached a majority consensus, it went forward with the decisions.

3. Tooling Friction

Not everyone in the mob could use the same laptop. Because of the time restriction, we decided to pass one laptop around, but this caused chaos. Language settings were different, keyboard layouts were different, special characters were hiding in strange places, and people were used to different IDEs. How smoothly can drivers rotate if they are constantly fighting unfamiliar tools?

4. The Enterprise Enigma vs. The Solo Dev

The results across the floor varied wildly:

• The Rotor Team: They spent 40 minutes on pure design. Since they only had to expose an API and didn't have to integrate with anyone else, they successfully built their logic. However, they never actually tested it to see if it worked.

• Our Team: We spent most of our time successfully handling the complex API integrations, but failed to code the reflector or even do a proper test with the rotor team!

• The Keyboard Team: They had to build an API and talk to ours. They also couldn't finish their implementation.

• The Solo Front-End Dev: One of the organizers decided to tackle the whole thing alone in parallel, focusing on building a browser UI together with implemenation. It's nice that front-end engineers always think of the user first, while back-end engineers just expose an API and say, "Good luck." He got quite far in the interface, but didn't get to finish the whole implementation to get an end-to-end encryption output.

Still, we couldn't help but think that the single front-end engineer was more productive alone than the 20 of us trying to build an Enterprise-level Enigma Machine distributed across three microservices.

5. Conway’s & Brooks's Laws

These two principles were in full effect, practically stopping us from implementing this quickly. How interesting would it have been if we had just created a monolithic server, put it on GitHub, and worked together on Git? But Conway's Law took over. Our natural instinct was to isolate into teams and create HTTP servers to talk to each other. It was encouraged by the organizers, sure, but nobody questioned it. Outside of our team nobody even put their code on GitHub to share; we just defaulted to calling HTTP endpoints.

Brooks's law was also in effect; we spent quite a lot of time trying to negotiate with other teams about how we should consume each other's services.

Conclusion

I'm really looking forward to the next event of this meetup. I absolutely enjoyed my time doing old-fashioned programming with people in a chaotic, hackathon-ish manner for a night, and I met some great new people.

If anything, this experiment proved exactly how vital communication lines between teams are. If you can only communicate with handwritten sticky notes, you desperately need to work on upgrading your systems. Code and code-based documentation turn out to be the ultimate universal communicators of ideas. In the end, the teams only managed to get things integrated when they finally laid eyes on each other's Swagger documentation pages.

Mob programming in itself seemed to be productive only when the major design decisions for example interfaces and algorithms are already there, not a surprise there because as software engineers don't just start coding, we design first.

One last thing, an arbitrary deadline as always pushes the team to be productive and use their time as efficiently as possible but it can also result it in bad design decisions that can be tolerated because of there's no time to do otherwise!