Carnegie Mellon put a Coke machine online to avoid warm soda

A trip to the Coke machine could end in an empty column or a warm drink. Carnegie Mellon programmers gave that disappointment a network interface. Soda, meet software.

The department’s preserved history collects recollections from people involved with successive versions of the machine. It is a charmingly untidy source: memories differ on dates and early hardware details. It supports the mechanism much better than a perfectly precise birthday for the internet-connected appliance.

Tom Lane recalls microswitches monitoring six columns and a PDP-10 tracking stock and elapsed time. The displayed status could distinguish an empty column from a cold one or a bottle loaded roughly an hour earlier. His remembered threshold for calling a bottle cold was about three hours, qualified in his own account.

A modified Finger server exposed the result through the nonexistent user coke. The preserved command is “finger coke@cmua”. Someone could ask for the soda’s status from another machine, including over the network. The result still required a human to fetch the drink. Last-mile delivery remained legs.

The technical charm sits in what the system chose to measure. A recently filled column could look healthy to a stock counter while producing exactly the drink the programmer wanted to avoid. Tracking elapsed time added the bit of context that turned inventory into a decision. A dashboard full of green squares can miss the same distinction whenever green means available and the person asking means ready.

The department’s narrative even gives the machine a voice, which jokes that a distant network visitor couldn’t do much with its information. True enough. Making data globally reachable doesn’t make every recipient a useful customer. For someone upstairs, though, that one small query could answer a real question before they stood up.

Later recollections describe replacement machines and a new interface, with different sensing arrangements. That creates a less glamorous dependency than the networking: someone has to keep the monitor matched to the physical machine. Change the vending hardware and the old measurements can stop meaning anything. The can-do spirit eventually meets the can dispenser.

There’s a nice design constraint hiding in all of this. The successful output is tiny. Six columns, their stock and enough timing information to choose a button. A general-purpose appliance platform would have added plenty of room for features without necessarily improving that choice. A person asking for cold Coke has a wonderfully effective way of ignoring the product roadmap.

For a modern monitoring project, the equivalent question is what decision the status must support. Showing raw sensor activity may be interesting; naming the condition that would make somebody take the trip gives the display a job. The record leaves the earliest dates fuzzy, even as that job remains exceptionally clear.

Cold comfort, successfully delivered.