I think it's a good thought exercise to give perspective on the challenge of getting clients to hand over good specs for software. Putting something into a fridge is simple and familiar, and here we see it's still a struggle to define a quality spec.

A client may say, "all I want is a button, why does that take two weeks an $20k to add?", and the developer who knows all the ways that button breaks the system's assumptions about data and behavior may have trouble expressing that to the client. The frustrated developer may wonder why it's like pulling teeth to get the client stop changing requirements, but in the client's head everything seems simple (like the fridge) until they encounter a bizarre behavior they didn't consider but the application code had to.

This article provides a good starting point for a discussion between client and developer about why their process needs to be iterative, and why its important to make requirements decisions early while they're still cheap to update.