Ardekantur

Imagine a very distinct, very specific kind of problem. Call it the Popsicle Problem. It goes a little like this:

It’s hot out. Unbearably so. You and a friend are driving in your car and decide to make an unplanned stop at your local convenience store. You grab a couple popsicles from the freezer, pay for them, and leave. On the long drive home, your passenger asks, “Are those popsicles going to stay frozen?” You shrug and say, “I dunno. Probably.” Your passenger looks out the window and thinks for a second, then says, “You know what would be awesome? If you had a cooler in the back for this sort of situation. Something you could just throw some ice packs into for whenever you had to drive something cold home.”

That’s the Popsicle Problem. Yes, that’s it. What’s wrong here? What’s the problem?

The problem is that throwing a cooler into the back of your car is a very specific answer to a very specific problem. How many times over the summer, much less the year, will you be making an off-the-cuff decision to have to drive frozen food a long distance? And what would you need to do to earn this pay off? Keep this completely arbitrary object in your car, and keep it stocked with ice packs, for this one specific situation. It just doesn’t seem worth it.

The Popsicle Problem is a transient problem. A temporary, one-off obstacle.

Software engineering seems incapable of solving transient problems because it sticks around and its existence works against the payoff.