Uncertainty: the final frontier
Photo credit: Stefan Cosma via Unsplash
When our schedules and streaming services are full of Star Trek content (at the last count, thirteen series and fourteen films), it seems hard to remember that the series was once a lonely, experimental long shot: the first regular science fiction TV series with recurring characters and themes, squarely aimed at adults.
Prompted by watching the (excellent) series Strange New Worlds, I tracked down a print copy of the book The Making of Star Trek, published in 1968, between the second and third season of the original series, when it was on the brink of cancellation. If you can put aside some of the 1960s-era attitudes (despite the generally progressive tone of Star Trek, there are some paragraphs that wouldn’t make it into a 2026 edition), it’s a fascinating overview of television production at the time, and of the challenges of getting studios and networks to try something new (and expensive).
But there was one particular memo that stood out to me. It is worth quoting in full:
To: All Concerned
From: STAR TREK Office
Date: June 15, 1966
Subject: CREATIVE BUDGETING
From time to time in the future, various departments will see in script descriptions of items or methods concerning them the term “(MEASURE).”
This term “(MEASURE)” is to indicate that our minds are by no means made up as to how we shall actually handle that set, or that special effect, or that kind of wardrobe or etc. This term will be a kind or personal code to all of us to put on our thinking caps. Is it too costly? Is there a better way, more effective, more believable, simpler and faster?
“(MEASURE)” means that we’re not sure about this item: We’re inviting you to be inventive and creative - and practical.
Hopefully, you will either show us a way to handle various budget problems, or else you will come up with alternative suggestions that will be much, much cheaper and much, much better to boot.
Gene Rodenberry
(The Making of Star Trek, Stephen E. Whitfield and Gene Rodenberry, page 168.)
The reason that this memo resonated with me is that we so often find ourselves in this situation when we are designing and building complex computer systems. If we are truly honest with ourselves, then we will admit that there are elements of any design which are, at best, placeholders: components which may or may not work; products which may or may not be a good fit; infrastructure which may or may not hold up when put under pressure. We know that the only way we will learn for certain whether they are good choices or not is when we put them to work. We also know that it is likely that some of the experts in our team will have better ideas.
There are three ways in which we can deal with this kind of uncertainty.
First, we can deny it. We can try to lock everything down in requirements specifications, systems designs, decision records and project plans, all of which look remarkably like non-negotiable contracts. This has the short term advantage of conveying comfort and confidence. Everything has been reviewed by the appropriate committees. Everything has been signed off. What could possibly go wrong?
Yet it only takes one project of this nature to show that the comfort and confidence are fleeting and illusory - most of the project will be spent changing requirements, revising designs, reversing decisions and re-baselining plans.
Second, we can embrace the chaos. We can avoid taking decisions until as late as possible - or put them off altogether. We can let the design emerge from the experience of the build. This has the short term advantage of allowing us to make rapid, visible progress. Everything is in the hands of the developers. Everything is capable of being changed and pivoted. What could possibly go wrong?
Yet it only takes a couple of projects of this nature before we start to crave a degree of order. We seem to be reinventing basic techniques and tools in every sprint. The structure of the system gets more complex every time we do a release. Performance is starting to degrade, and we have a suspicion that the next pivot will be towards a total rebuild.
Third, we can follow the approach outlined in Rodenberry’s memo. We can identify those parts of our design in which we are clear and confident, but also designate those parts where we don’t have all the answers. We can recognise that the work we do next does not mean simply following the design: it means thinking hard, and validating or challenging the remaining areas of uncertainty. It means walking a middle path between apparent certainty and genuine chaos.
Despite being infamous for having a very clear vision for Star Trek, as his memo shows, Rodenberry did not define a fully locked-down set of rules in advance: he expected people to improvise. At the same time, he was not operating without vision or without constraints: the series had to fit within time and budget, and had to be sufficiently consistent and believable for people to stick with it.
Perhaps in our systems designs and architectures, we should adopt the label “(MEASURE)” to acknowledge the placeholder elements of our design, and to invite alternatives. We are not clueless, and we are not seeking chaos, but we are humble and hopeful enough to realise that we might be wrong, and that someone else on the team might come up with something better. This term will be a kind or personal code to all of us to put on our thinking caps. Is it too costly? Is there a better way, more effective, more believable, simpler and faster?
