I’m continuing with the theme of cool activities with my excellent colleagues in Granada, in addition to our classics like playing board games and going out to eat together in good restaurants.
The time before last, I suggested a coding game.

On the advice of my friend @riduidel/Nicolas Delsaux, and because I’m not familiar with this sort of thing, I chose the extreme carpaccio game.
You can find all the details here:
https://github.com/dlresende/extreme-carpaccio

I’d encourage you to read the description of the game, at least from the players’ point of view, if you intend to play it. When I say ‘play’, yes, it sounds like a kind of TTRPG with code. It’s a fun, competitive game in which several teams compete by delivering code and trying to score points.

That day, five developers were present, plus the monitoring supervisor, the quality supervisor, a PO and the support supervisor. I asked them to get together in 4 groups (3 groups of two, one group of three), each containing at least one dev, the other being a ‘manager’. Each group represents a small IT company to which the Big Client (me) orders an e-commerce system.

The game is available on the github repo above and is very well done. The GM deploys a server that sends orders to the players’ systems. The players have to accept the commands, do a little calculation on them according to the specs and send back the result of the calculation. If they get it right, they score the amount of the order in points. If it’s wrong, they lose half the amount in points. If the answer is 404, no gain, no loss.

We were in a large room, reserved for two hours. With the result, in points, displayed on a big screen.
The game is very well prepared. If you’re planning to run it, allow one or two hours for preparation at home, just long enough to master the technical tools (the only thing I missed was knowing that a NodeJs app deploys by default on port 3000), plus half an hour at the game venue to test the network config (basically, deploy the server on one machine, the clients on another, play with ipConfig, and check that it’s working).

First thing’s first, it’s great fun. If you’re feeling a bit like a storyteller, this is for you. You can play characters, do big voices, bang on the table, wave your arms… And the players can play the smooth-talking manager who appeases the customer, make impossible promises and so on. It’s a great way to let off steam and have a good laugh. The screen that displays the points immediately shows whether it’s working or not. I’d set up 10-minute ‘sprints’, so that I could count the time in the game (‘at what sprint are you going to deliver in production?’), which isn’t included in the scenario.

All the teams delivered, delivered late and lost points before recovering them.
At the end, we spent around twenty minutes debriefing. Each team will learn its own lessons (ours are below, beware of spoilers).
I’d recommend this game, everyone had fun (devs and non-devs), we were really able to laugh about what sometimes makes us stressed and say things we wouldn’t have been able to say before.

SPOILERS

DON’T READ THIS BEFORE PLAYING THIS GAME

• The code to write is simple, the specs are clear
• but the stress, noise and pressure make many good practices go out the window
• the ‘manager’ of each team has more or less played the role of intermediary with the Big Client (the GM, who scolds and grumbles)
• obvious elements were ignored, resulting in lost points (return 404 when you don’t know where there is an error)
• experienced devs have made rookie mistakes
• no team wrote a single unit test. (some didn’t even realise that the proposed code skeleton contained tests) even though this is an established dev practice and the specs propose test data
• everyone was psychologically fooled by the big time counter on the screen without realising that the division into ‘sprints’ was purely artificial and didn’t correspond to anything real.

All this enabled us to see, outside the game, how the evolution of the open space (the team now works in a less quiet environment) and the more frequent interruptions linked to production (and to unplanned requests from management) have a major impact on quality and production, despite an increasingly experienced team.

I’m the manager of a great team, based 1,588 km from where I work. I can see the Alps through my office windows, they’re in Andalusia and can see the Sierra Nevada. So I spend a lot of time chatting to them via Teams, a sad avatar of modernity. At least we talk to each other and see each other every day.

Fortunately, once or twice a year we’re lucky enough to spend a week together. We then try to organise or create group activities, which take us out of the rhythm of sprints and deliveries.
Last time, following my visit to Snowcamp where a speaker recommended it, we did an hour of collective reading of Brooks’ classic chapter, “No Silver Bullet: Essence and Accidents of Software Engineering” (1986). I wondered if this old text would speak to a team none of whose members were born when it was written (apart from me…).

I was just discovering the text and found it incredible. Almost forty years old and still relevant reflections to answer the question: why is it so difficult to carry out IT development projects, and why is it that, while computers are becoming ever more powerful, IT projects are always lagging behind?

The title compares a development project to a werewolf. Innocent at first glance, a project like any other, which sometimes, often, turns into an uncontrollable monster that eats up budgets and deadlines. And Brooks demonstrates that there is no silver bullet that can put an end to it.

The text is short and dense, and I won’t insult you by summarising it. If you’re intrigued by the subject and don’t already know about it, read it.

Collectively, here’s what we did: I asked those who wanted to to read the text in advance (everybody did). Then, on the same day, I gave a brief introduction to the author, werewolves and the question posed by the text. Then I asked the team members to identify the main ideas in the text, which we put together collectively, and we discussed some old points (time-sharing) and some more recent ones (AI & expert systems).

Rather than listing our summary here, I’ll just quote a few extracts that I really liked.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

I really like this idea of a human construct, so vast and complex that it has thousands of parts, all different.

[Software] is pure thought-stuff, infinitely malleable

There’s something that links my two great professional passions: writing novels and writing software. As a teenager, I loved touching my first word processor and discovering that I could change everything infinitely. In fact, I think the term ‘infinitely’ is a bit misleading. Eventually you get tired of changing everything and programmes, like novels, crystallise.

Software is invisible and invisualizable

This idea also makes you dizzy. Our team is responsible for half a million lines of code, it’s our domain. We have no way of seeing all the details at a glance. Even our diagrams and plans are only partial indications. We are responsible for a labyrinth in which we are constantly laying down guidelines for the programmers of the future who will pass through it.

The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide_perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important.

Very good vision of the impact of Copilot-like tools, even if Brookes didn’t anticipate the negative consequences…

What would you recommend for future team reading? Extracts from Clean Code or Pragmatic Programmer? The passage from Jurassic Park describing the bug in the surveillance system? All ideas are welcome!