I’ve been reorganizing my home office lately: changing out one desk for another, rearranging shelving, clearing away clutter. In the process, I came across boxes of notebooks I had stored away. One box on a shelf contained relatively recent journals. Two more boxes buried in a closet held notes dating back to 1987.
I flipped through a few of the older volumes. Much of the content was my reflections on software development in general, flavored with the particular challenges I was facing in my job at any given time.
Memories flooded back…
...the dotcom-era Silicon Valley startup where we hired testers so fast that we had nowhere for them to sit and nothing for them to work on. I remember a confrontation with the head of the department where I refused to interview any more candidates until we had properly onboarded the people we’d already hired. As you can probably imagine, that conversation went very, very badly. I have learned much about both diplomacy and keeping a rein on my temper since then.
...the established enterprise product with a small number of high value customers, each of whom had slightly different needs and expectations. It was incredibly difficult for the organization to prioritize work and deliver a product that continued to meet all the customers’ needs. I remember struggling with how to manage expectations with stakeholders who all had competing needs.
...the release where I saw that we were going to miss the deadline just a few weeks into the project, but the Engineering VP didn’t want to hear it. I recall that he and I had numerous vigorous debates about the release schedule. I wanted him to push the schedule out instead of imposing an impossible deadline; he wanted me to stop being so negative. We never did come to an agreement about the schedule. Instead, the release slipped day by day, week by week, in a demoralizing slog. When the release eventually shipped, it was long after the original deadline and within days of my prediction. (My earlier lessons in diplomacy paid off: I resisted the temptation to say, “Told you so.”)
...the time when the executives in the company convinced themselves that it would take no more time to do two releases than one because the developers were, “just waiting on QA to finish testing anyway.” They called this parallel release plan “a slipstream release.” (It did not go the way the executives had hoped.)
...the project where there were so many moving parts, it was next to impossible to keep all the components in sync with the messaging protocol and deployment configuration options. The test suite was supposed to catch problems but no one felt a sense of ownership over the tests, so they were always red.
Story after story. As I scanned the pages, I relived the experiences. Some of the memories made me smile, but many more were painful. I found myself wondering: “what if?” What if things had been different? What if I had learned that lesson sooner? What if we had tried a different approach? What if I’d had a way to help someone else see something I saw clearly?
We all have these stories. Anyone who has been in tech for any period of time has a story about the never-ending release, or the bug that wouldn’t die, or the horrifying realization that the right question isn’t “why is this broken?” but rather “how did this ever work?”
I want to bring these stories to life. I want to test my intuition and discover possibilities I hadn’t seen before. And not just my stories. All the stories. I want to experience others’ challenges, and give others a sandbox, a safe space to try out experiments without jeopardizing real projects. No matter what the simulation work I’m doing now turns into, this is what drives me.
The difficulty lies in defining a set of primitives that offer a rich enough model without becoming over-complicated.
Over the last week I’ve been making important but mostly subtle changes to the first published scenario to make the flow of unplanned work a little more realistic. When I turned my focus to the second scenario, I realized that the simulation engine’s model of deployments and bugs is overly simplistic.
Two steps forward, one step back.
Each step back requires me to revisit the model, adding code to make it a little more realistic or flexible. It’s a little scary to see it continuously growing. I keep hoping for a moment of convergence, a turning point where each new scenario can be expressed using existing primitives. I am still optimistic that the model will converge, just not quite yet.
Over the coming week I will continue revising the first scenario, improving the user experience and addressing more of the feedback from user interviews. I will also tweak the model to support the second scenario, making bugs feel more realistic.
As noted in last week’s newsletter I’ve paused the user interviews for now but will start up again when there’s enough new content. In the meantime if you’d like access to the pre-pre-pre-release site, please email me at email@example.com.