The Three Microwave Ovens

In computer science and software engineering, it is essential that every program or part thereof written to solve a particular problem solves that problem in its entirety. It is critical for programmers to be careful when they make assumptions, and to avoid hasty generalization about the tasks their code is to perform. After all. I would hazard a guess that most programmers assume that the code they produce is correct, and yet errors still exist. Some errors are immediately apparent, while others are only noticed after a program is relied upon by users. Still others stay dormant until activated under precisely-engineered conditions by an adversary attempting to breach the security of a computer system.

One of the most common—yet the most insidious—type of error comes from programmers making hasty generalizations about the nature of the problem their code is to solve. What is true of most inputs many not be true of all, and examples of correct behavior used to guide the implementation of an algorithm or test such an implementation may not represent the full spectrum of possible inputs. Handling "edge cases"—situations or inputs that warrant special handling, or those that deviate from the norm—and "corner cases"—more atypical than edge cases—is a tricky task for so many programmers. Edge cases are the cause of so much misery on the part of programmers and users alike, myself included.

As a scientist, I have the power to observe how the world works, the knowledge to describe it, and the drive to find out the principles that define why it works the way it does. I have therefore taken a serious interest in a particular facet of how most microwave ovens operate¹. Nearly every microwave² operates the same way³, to wit: after pushing a button or pulling a handle to open the door, the user sets their food down, closes the door, enters the duration of cooking⁴ using a keypad—with the last two digits entered specifying seconds and up to two digits before those specifying minutes—and presses "start". To cook something for 45 seconds, one enters 45; to microwave something for 1 minute 30 seconds, one enters 130. So far, all is well.

But what happens if a user enters 99 or 180? A time of 0 minutes 99 seconds is certainly unambiguous—equivalent to 1 minute 39 seconds. So is a time of 1 minute 80 seconds. But they aren't what most people see as possible representations of time. They violate the place value (however alien to our decimal world and however shoehorned into our system of numerals) that is inherent to representing time in hours, minutes, and seconds. These times are the quintessential edge cases, and it falls to microwave firmware developers to handle them properly.

As someone who likes to think exclusively in seconds, and who likes to save a button press by entering times of more than 59 seconds rather than specify minutes, I am well aware of how different microwaves handle this edge case. Each of the three behaviors that I've identified reveals a different approach to programming a microwave to process time. In my experience, no microwave has behaved pathologically when presented with this nonstandard input.

The first approach is to reject any input with a seconds field greater than 59. Rejecting pathological and ambiguous inputs is a well-established good practice of programming, and it seems likely that these microwaves were explicitly programmed to reject inputs not matching a more narrow conception of what constitutes a valid time. While most users do not care, I am slightly displeased with this approach, as it rejects inputs that are completely unambiguous and—in my view—valid, and represents an impediment of 3 or so seconds to me operating that type of microwave.

The second approach is to accept inputs with a seconds field greater than 59, but to immediately reformat the time displayed to an equivalent value with a seconds field less than or equal to 59. Thus, entering 190 and pressing "start" would cause the microwave to display immediately a value of 2:29 and count down from there as normal. In my view, this is indicative of a microwave that stores the time remaining in seconds and calculates the displayed time from that. In pseudocode, that would look something like this:

 1total_time = input_m * 60 + input_s
 2
 3...
 4
 5# total_time-1 is used to prevent an off-by-one error.
 6for time_remaining in reverse(range(0, total_time-1))
 7  sleep(1)
 8  display_m = floor(time_remaining/60)
 9  display_s = time_remaining%60
10  display_time(display_m, display_s)
11  ...
12end
13
14...

This is certainly how I would program a microwave, but I'm not a microwave firmware developer and am likely never to be one.

The third approach—in my experience, the most common—is to accept inputs with a seconds field greater than 59, display the time exactly as given, decrement the seconds field once a second, and then continue as normal. For example, if given an input of 190, a third-approach microwave would start at 1:90 and count down to 1:61, 1:60, 1:59, ..., 1:00, 0:59, and so on. This approach suggests to me that the microwave stores the minutes remaining and seconds remaining separately, decrementing the seconds field once a second and adding 60 to that field whenever it reaches 0. This is implemented in the following code:

 1time_m = input_m
 2time_s = input_s
 3
 4...
 5
 6while time_m != 0 && time_s != 0
 7  sleep(1)
 8  if time_s == 0
 9    time_s = 59
10    time_m = time_m - 1
11  end
12
13  display_time(display_m, display_s)
14
15  time_s = time_s - 1
16end
17
18...

As I've said before, this entire phenomenon is a result of there being no clear way to handle this odd—yet entirely possible—type of input. As a result, programmers are free to handle it in whatever way makes sense to them—and that reveals something about how their code handles timing more broadly. One lesson that I've learned in part from science is to be as observant as I can about the world, and one lesson I've learned from computer science in particular is that I can learn very precise details about how a system works by examining how it handles conditions that are not necessarily expected, standard, or typical.