You might be wondering what this is. As of this writing there is so little information on the site. What is Curious Duck Digital Laboratory? Why is this site here? What is this newsletter?
I'm going to explain, but to do so I have to start at the beginning.
I love software. It is made entirely of ideas, constrained only by imagination. Where matter obeys the laws of physics, software has no such limits. Software is magical.
(Of course software runs on hardware, and hardware exists within the confines of reality. And some software is so tightly tied to the metal it runs on that it exists in both the world of atoms and the world of electrons. But most software folks can ignore the details of hardware. After all, what is cloud computing if not the triumph of software over physics?)
Although software itself is magical, there is no magic in building software.
Technology is an ever-changing landscape. Delivering production-quality software is hard. Software development is non-linear. Cause and effect do not always seem connected in predictable ways. A tiny change in a core library can cause subtle yet pervasive and devastating bugs downstream.
Worse, what you learn about delivering software in one environment may not apply in another. We cannot separate the software we build from the organizations in which we build it. The practices that work for a close-knit, co-located team won’t work for a highly distributed team that operates asynchronously.
You could lean into general strategies for improving your odds of success. If you want to reduce late-breaking surprises and risk, find ways to shorten feedback loops. If you want to improve coordination, find ways to create visibility. Always remember it’s people who power software and treat them with respect and kindness.
However such strategies are easy to describe but difficult to implement.
Imagine you want to find the right points of leverage to improve the timeliness or quality of feedback. "Automate the tests!" might sound good but it is overly simplistic. Which tests? Who should automate them? Who will care for them when they inevitably break? The things we can automate might not even be the source of the most useful information.
Similarly, visibility sounds great until it creates incentives to game the numbers to make them look better. How can you make things visible without adding unintended pressure from heightened attention?
That's the thing about building software: nothing is ever quite as simple as it looks. Address one problem and another one crops up. There are no perfect answers. At best you get to choose which problems you want to be stuck with. It can take years to be able to reason about the implications and tradeoffs in a situation or set of decisions.
If you want to get very good at delivering software and don't want to spend years learning the hard way, what are your options? Experience is the best teacher, but it takes too long.
That's the power of simulations. They abstract away the details, establishing a set of game mechanics that distill situations down to their essence.
What if you could play Software Development: The Game?
You start as an individual contributor and work your way up to executive. Along the way you have to make choices, and those choices involve tradeoffs: Do you pay down technical debt or push forward to deliver a feature your stakeholders have been pressuring you about? Do you invest in shortening the build cycle or improving the quality of the tests? The more you expand your role the greater visibility you have across the entire system, but the less direct control you have.
The game is still very much in development and not yet ready for playtesting. When it is, I’ll announce it here. In the meantime I’ll be sending weekly updates on Tuesdays. My goal is to make every issue of this newsletter earn its place in your inbox with actionable advice, pointers to useful resources, and a backstage pass to watch as we build the game.
With that, it’s time for me to turn my attention to building a playable scenario. See you next Tuesday.