What Software Has in Common with Schrödinger’s Cat

In 1935, physicist Erwin Schrödinger proposed a thought experiment to explain how quantum mechanics deals only with probabilities rather than objective reality.

He outlined a scenario in which a cat is placed inside a sealed chamber. Inside the chamber is a flask containing a deadly substance. There is a small bit of radioactive material that has a 50% chance of decaying within a specified time period, say an hour.

If the radioactive material decays, a hammer breaks the flask and the cat dies. If it does not decay, the contents of the flask are flushed safely away and the cat lives.

(This would be a barbaric experiment if it were real, but remember that this is only a thought experiment. No actual cats were harmed.)

If we were to leave the apparatus alone for a full hour, there is an equal probability that the cat lived or died.

Schrödinger explained that in the moment before we look inside the box to discover the outcome, the cat is both alive and dead. There is no objectively measurable resolution to the experiment…yet. The system exists in both states. Once we peek (or by any other means determine the fate of the kitty), the probability wave collapses.

When I first read of Schrödinger’s Cat in my physics class, I was befuddled. A cat is alive, or dead, not both. I did not understand the idea of a probability wave that contained both possible states.

So I can understand completely if you are thinking, “Look, the dang cat is dead. Or not. And besides, this is not related to software AT ALL.”

Ah, but it is.

You see, in the moment we release software, before users* see it, the system exhibits the same properties as Schrödinger’s feline.

There is some probability that we have done well and our users will be delighted. There is another possibility: we may have missed the mark and released something that they hate. (Actually there are an infinite number of possibilities involving various constituents with varying degrees of love and hate.)

Until the actual users start using the software, the probability wave does not collapse. We do not know, cannot tell, the outcome.

For teams that believe they are building awesome stuff, the moment before users get their hands on our work is a magical time full of excitement and wonderment.

For teams that believe they are building a pile of bits not suitable for human usage, it is a time of fear and panic.

But both fear and excitement stem not from observable reality but rather from speculation.

We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us.

We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking.

We are speculating that we knew what the users actually wanted in the first place.

We are speculating that the tests we decided not to run wouldn’t have found anything interesting.

We are speculating that the tests we did run told us something useful.

None of it is real until it is in the hands of actual users. I don’t mean someone who will poke at it a bit or evaluate it. And I don’t mean a proxy who will tell you if the users might like it. I mean someone who will use it for its intended purpose as part of their normal routine. The experience those users report is reality. Everything else is speculation.

This is what teams forget in that heady moment just before release. They experience all their excitement or terror, confidence or insecurity, as real. We forget that reality is meta-surprising: it surprises us in surprising ways.

And this is why Agile teams ship so often.

It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact.

In short, frequent delivery means we live in reality, not probability.

Facing reality every day is hard. Ignorance is bliss, they say. But living in the land of comforting illusions and declared success is only blissful as long as the illusion lasts. Once the illusion is shattered, the resulting pain escalates with the length of time spent believing in a fantasy and the degree of discrepancy between our beliefs and the actual results. Given sufficient delusion and lengthy schedules, the fall to Earth can be downright excruciating.

I’ll take small doses of harsh reality over comforting illusions and the inevitable ultimate agony any day.

* I use the term “users” here to represent both users (the people who use the software) and customers (the people who decide to buy the software).

If you are buying yourself a game to play, you are both the user and the customer. In sufficiently enterprisey systems, the customer might never even see the software. In that situation the customer and users have very different concerns, so it’s a more complicated probability wave. After all, if the customers love it but the users hate it, was it a success or failure? I’ll leave that discussion as an exercise for the reader.

14 thoughts on “What Software Has in Common with Schrödinger’s Cat

  1. Great post!

    Another great argument for continuous delivery (where responsibly possible) if you’re constantly delivering features and measuring the outcome either through interacting with users, or otherwise measuring some meaningful metric that translates directly to customer delight, you can adjust your product development to suit your user base.

    Of course there are many factors that increase the expense of continuous delivery, but if your context allows it and your product permits that level of customer interaction, I have to imagine your team will all benefit from the knowledge that they’re working together to deliver something that matters and that their work is constantly producing a meaningful contribution to the success of the org.

    Great stuff!

  2. We could stretch this analogy even more into the real of quantum mechanics by applying the double-slit experiment. If we look at the feedback that we get from *real* users on a case-by-case basis then we will be collecting bad data. That’s because what a user actually experiences and what they report are two different things. They might have an enjoyable experience with the app yet turn around and give less than favorable review because of something totally outside of the app – maybe they got bad news in the time between using the app and writing a review.

    And it can swing in the other direction as well. Some people are just too nice and won’t report things they don’t like.

    The problem I’ve seen is that managers are all too willing to take feedback – usually bad feedback – to heart. They think that if one person feels very strongly about something they probably need to change it.

    The lesson is: don’t ever base changes on individual reviews/feedback. Wait for trends to develop in the feedback before leaping to conclusions. One individual data point is meaningless and may not even accurately reflect the true thoughts of a user.

  3. Excellent article. I remember talking a lot about “Schrodinger’s Code” on a troublesome (waterfall) project I was on last year.

    The assumption from management was that all our vendors promises were true and on the nose, so why lift the lid on the box to check if the cat’s still alive? The (somewhat bizzarre) conclusion was the project was running fine until testing went and ruined everything.

    But you’re absolutely right, delaying testing as happened was just an exercise in delusion. As long as we don’t lift the lid, we can convince ourselves the cat’s still alive.

  4. I wonder what thought process the cat is going through … wave function collapse causing one to speculate inside the box.



  5. About the bugs speculation, I would like to add the following:

    “We hope that it’ll take our users years to discover a bug that we saw in 5 minutes of testing and chose not to fix because we were too lazy to do so”.

    I really like the cat story in the beginning… A great introduction.

    PS: You might find this post useful (it is on constant testing by the users).

  6. If I was in the cat’s shoes I would insist on knowing the answer before agreeing to go into that chamber.

    Similarly, I would want to know that customers will be delighted with the software *before* writing the code.

    Eric Ries and Lean Startup Help Schrödinger’s Cat Live Longer

  7. This is still my favorite article you have authored:
    “Arguing Apples and Oranges” http://www.stickyminds.com/s.asp?F=S6323_COL_2

    It’s nearly 9 years old and I still look it up on occasion to send the link to someone.

    This article is a close second though …I had not considered deployments in this context and I’ve been in the industry 20 years. Nicely done Elisabeth!

  8. Nice analogy, and I like the thought that frequent releases can keep the wave down to a ripple.

    Schrodinger would have been pleased with your initial reaction to this thought experiment: he was trying to point out the counterintuitive implications of the Copenhagen interpretation of quantum physics.


  9. I very much agree. We should not muse much about whether the code cat is alive or dead – we need to look 🙂

    With daily delivery/acceptance the box open and closed at the same time, so to speak. It´s closed for the day. But then it´s opened for the release to flow out. That´s like watching a film: the illusion is, there is continuous movement – but in fact it´s just snapshots.

    But daily acceptance – which I call Spinning for it´s high frequency, see here for details: http://geekswithblogs.net/theArchitectsNapkin/archive/2011/12/23/get-into-the-flow-with-spinning.aspx – has more advantages than just frequent feedback:

    * Higher flexibility: The customer can change the course of development every day.
    * Less waste: The customer can stop work on a feature before it´s completed because she thinks its good enough.
    * Increased evolvability of code base: A team cannot sustain such a high frequency without writing clean code. Refactoring becomes the norm not an exercise to schedule if deemed necessary.


  10. Great post!

    I would like to add that we must not forget the variable of software running environment that has its own probabilities. For example, probability of the variable latency between user and our enterprise application.


  11. Pingback: Why software has nothing in common with Schrodinger’s cat « Jack of all trades

  12. Elisabeth,
    Software part is great. Physics part, AFAIK, has utter wholes. Quantum mechanics do not apply to macro objects (like cat or software). Shroedinger never implied the opposite. Thus, your first impression (“a cat is alive, or dead, not both.”) was correct, and it’s *the only* correct interpretation.

    I tried to explain a wee bit wider in a blog post http://ilyakurnosov.wordpress.com/2012/01/06/why-software-has-nothing-in-common-with-schrodingers-cat/

  13. …and since we all get paid on the basis of reality and not fiction (at least, not in any sustainable way) thus is the ultimate importance of collapsing that probability wave. We need to know as often as possible what the real results of our work are, and not from our own imaginations.

    Well written, thanks!

Comments are closed.