
What Can You Put in a Refrigerator? - rnicholson
http://prog21.dadgum.com/212.html
======
TeMPOraL
The more I have to deal with corporate project management patterns, the more I
think the whole approach behind specifications is wrong. Trying to focus on
what the "domain objects" are and what is their flow is pointless, especially
if you're dealing with real-world objects (like the fridge from TFA). You can
model _something_ this way, but it will be usually the imaginary perfect path,
a narrow vision of how things _should_ be done, that will break on first
contact with the real world - a world that is messy and requires humans to
improvise on the spot.

I'm starting to believe that one should focus on the workflow instead. After
all, the reason for writing software as a tool is to simplify or automate some
existing process. So focus on what people are already doing and what they're
trying to achieve and find a way to remove repetitions, unnecessary delays,
etc. Just look on what people are doing and find a way to do some parts of the
process faster and better.

~~~
josh64
That's where user stories can help:

"As a user, I want to store my food and drinks in the refrigerator so they
don't spoil"

"As a user, I want to store drinks in the refrigerator so I can drink them
cold"

"As a user, I want to store my medicine in the refrigerator so it can stay
below 25 C"

------
hapless
The original spec, "Anything that fits into a refrigerator," is a pretty darn
good one. It conforms to Postel's law: "Be conservative in what you do, be
liberal in what you accept from others".

We can develop a spec in a vacuum, but we can't be sure what users actually
want from our refrigerator. Maybe a live penguin actually _does_ belong in
there, as in the famous children's novel.

~~~
silentplummet
Can you put a baby or pet into a refrigerator? What about a freezer?

~~~
chaz72
Well, it isn't the _refrigerator_ that's going to stop you.

~~~
other_herbert
Yes! Things shouldn't prevent all the crazy that's out in the world... Users
will try to find creative ways around requirements, being more graceful in
handling the crazy is usually appreciated

~~~
petke
On the other hand "Make doing the right things easy and the wrong things hard"
are good design rules. Putting something alive into a refrigerator and leaving
it there, will probably make it dead. It might be a serious mistake by the end
user. The smart refrigerator of the future might want to double check; "Are
you sure you want to put the milk in the crib and the baby in the
refrigerator?"

------
miguelrochefort
"Any contained item that can fit inside a refrigerator, whose quality would
degrade significantly more when kept at room temperature rather than at 1-4°C,
by the estimated time of use/consumption."

The term "contained" above is restrictive, and probably needs further
precision. Only things that thrive inside an opaque and sealed container would
fit the definition above. Otherwise, things that can affect the quality of
other items (i.e., gas emanation), things that need light, things that need
oxygen, things that need a specific range of moisture, things that can grow
and/or move, would all need their containers to provide these conditions
and/or have a dedicated location inside the refrigerator.

~~~
SixSigma
* Puff pastry that needs to be chilled for five minutes so that the butter doesn't melt into the flour before you do the next roll.

* Jello that needs to be set

* Sprouted beans / seeds for which you want to restrict the rate of growth

~~~
miguelrochefort
"Any contained item that can fit inside a refrigerator, whose quality would be
better if kept at 1-4°C rather than at room temperature by the time it's
used/consume."

~~~
cdcarter
I've definitely just placed a stalk of broccoli on the bottom shelf of my
fridge with no container.

~~~
PhasmaFelis
I would argue that the broccoli contains itself, or perhaps that the
skin/surface of the broccoli is the container. (Though some people would argue
that all vegetables in the fridge should at least be bagged, to prevent
transfer of germs/grime.)

------
sparkie
Anything the user decides to put in the refrigerator, provided we put warnings
in small text on the document that accompanies the refrigerator for catogories
of items we know to be unfit for the refrigerator so as to cover our asses if
the user does not heed our warnings.

In terms of software, trying to decide up front for the user what they can do
is the wrong approach. Even constraining them is flawed, with the exception of
constraints for liability issues. What the user needs is the meas to express
their decision making as to whether something should go into the fridge, so
they need an input mechanism capable of doing selection, which has access to
the context in which the item might be being placed into the fridge.

Does this sound like any configuration format you've ever used? The typical
key-value stores which attempt to give you a declarative list of what you can
put where, without the means to compute whether or not it might be a good idea
first are almost ubiquitous, and the number of programs which take the right
approach: give the user a proper, expressive programming language to configure
the software, are few.

Just as it happens, we've developed ACME Refrigerator v2.0, which now allows
you to store chocolate bars in it; a feature we missed in v1.0. Upgrade now
for just $400.

The absurity of this idea with a fridge seems lost in software because we can
upgrade at almost zero cost in just a few minutes, but that's only masking
what is an obvious design flaw.

Which raises the question: What can you put in a software package definition?

------
jtheory
Fun read. This reminds me of how "object-oriented" programming goes wrong for
beginners. ...Not helped, alas, by all of the texts that thing it's helpful to
demonstrate OO concepts by modeling things like "cat is a subclass of animal"
:/

~~~
Retra
Not to derail too much, but.

I had a textbook that started to explain OOP by basically saying "A dog is a
class. A dog has a tail that can be in a wagging state or not. A dog has a
name..."

And I'm sitting there thinking "No, dog's don't 'have' names. We call them
names and they respond to names. They sometimes know their name. It's a
different kind of 'have' than having a tail. I have a name for my dog. Should
the person class have a dogs_name member variable now?" A tail is a subset of
a dog. A name is a property of the abstract system in which the dog resides.

A class is a model of something else. You can model a dog with an object, but
you can't know how good of a model it is unless you dig down into it and see
where it breaks down. It _will_ break down, because software is an
abstraction, and abstractions, being abstract, are _not_ the things they are
abstractions of. And there are not many things that behave like OO objects
because they are far too simple to represent reality in any high-fidelity
sense. And it's dishonest to pretend they do.

Not to say there isn't some pedagogical advantage to using the analogy, I just
think a better one could be used. Like talking about messages or something.

~~~
percept
Hopefully it wasn't "POOP":
[http://www.amazon.com/gp/product/1878739441](http://www.amazon.com/gp/product/1878739441).

------
CapitalistCartr
This essay assumes the wrong answer. The intelligence has to be built into the
item, not the appliance, just as we do now. Packages have messages such as
"Refrigerate after opening" on them. Anything that needs to be refrigerated
will need to communicate that need, along with details such as temp, to the
automated system.

~~~
collyw
Best before dates are a waste of time. I noticed this travelling in less
devloped countries where they don't usually have them. And plenty of times I
have had chicken that smells off despite being before the date on the packet.
I had one cheese that got way better after being a month past the date.

~~~
adrianN
Best before dates are a really good idea if you want to reduce the number of
food poisonings in a large population. Food is (statistically) very safe
before the best before date, assuming proper storage. Most of the time it's
still safe well past that date, but you would dramatically increase the number
of people who get sick.

It's the same with pasteurized milk. Unpasteurized milk is mostly safe to
drink, but occasionally you get really sick. In a large population the
difference is noticeable.

Again the same with the much stricter cleanliness rules for restaurants and
the like. Usually it's safe to store prepared food without refrigeration for a
day, restaurants mustn't. It's also mostly safe to cook on a dirty stove,
restaurants mustn't. The difference between your home kitchen and the
restaurant is the number of people served.

~~~
nommm-nommm
Best before dates have nothing to do with safety, they are about quality. They
are (mostly) voluntary and set by the manufacturer.

[http://www.webmd.com/a-to-z-guides/features/do-food-
expirati...](http://www.webmd.com/a-to-z-guides/features/do-food-expiration-
dates-matter)

------
Symbiote
The question is wrong, as it stands the answer is "any non-fluid or contained
fluid that will fit".

"What should one store in a refrigerator?" is a better question.

~~~
i736680
I would argue that pretty much anything you would put into your refrigerator
is contained inside packaging. Sometimes that packaging is just a simple
plate.

~~~
TeMPOraL
I put a cat in the refrigerator more than once - for some reason, my cats
loved sitting there for few mintues long when there were young. There were
definitely _not_ packaged.

------
farhanpatel
It reminds me of this "What is a Photocopier?"

[https://www.youtube.com/watch?v=PZbqAMEwtOE](https://www.youtube.com/watch?v=PZbqAMEwtOE)

------
zombees
"Anything that fits in the refrigerator and will remain contained within it."
Covers all uses for refrigerators and prevents anyone from putting bulk
liquids, penguins, coyotes, live hand grenades, radioactive material, nuclear
weapons or Indiana Jones inside.

~~~
GavinMcG
But not pet hamsters!

------
mikepalmer
Reminds me of a question I have been wondering about: Can you formally specify
what is the purpose of a suitcase?

In principle, you could dump all your clothes, toiletries, etc. in a pile on
the airport checkin counter, and if system were organized enough, it could
deliver all your stuff to hawaii and lay it all out on the hotel bed for you.

E.g., a robot would scan all your belongings at the airport, and dump them all
into a big pipe... each item would get properly routed to your hotel room...
kinda like how the internets work!

Is it just a question of organization? "Everything in this suitcase belongs to
this person and should move together to the same destination."

~~~
stordoff
> kinda like how the internets work!

Using this analogy, isn't a suitcase roughly equivalent to a packet? It's
tagged with source/destination, and basically standardised so the routing gear
doesn't need to care about the specific items you are routing.

~~~
andrewingram
You know, I think the analogy might actually be the wrong way round....

------
pheroden
Bacon, cheese, steak, and bottled beer. Being single sure makes writing specs
easier.

~~~
mikepalmer
don't forget ketchup.

~~~
rdancer
Heathen!

------
platz
I think this is hinting at the problem that occurs in OOP, when the business
rules of the system are expressed with virtual methods in classes as part of
an inheritance chain, in the business domain

Example: eric lippert tries to model an RPG in OOP and tries to model the
character "uses" command: [http://ericlippert.com/2015/05/11/wizards-and-
warriors-part-...](http://ericlippert.com/2015/05/11/wizards-and-warriors-
part-five/)

------
Sniffnoy
Anything that you can fit in and that you can also easily get out again.

(The latter requirement rules out not only liquids but also e.g. a pile of
salt or rice.)

~~~
coldtea
So, your pet cat?

------
chetatkinsdiet
If this is how you're defining requirements for software or new product
creation you're doing it wrong.

The goal should never be to describe every single outcome or scenario- the
goal should be to build understanding between business/product/development
team so that they understand the point of the work that the software replaces.
It's no different with hardware or really any new product creation. The goal
is to create a conversation that gets us to solving the problem- when the spec
gets to covering all cases the chances we get this wrong and stray from
solving the actual problem goes up massively.

~~~
Idontagree
The article is making a point about understanding or what happens in a
conversation for something like requirements, neither you nor him provided an
exact answer as to how to define requirements, because it's something we
havn't yet been able to automate.

Also it's starting a conversation about the very topic..

~~~
chetatkinsdiet
Good point- that all said, if we're automating requirements we're not solving
the problems that tend to matter. The key to requirements building is in the
process. The best process I've found so far is User Story Mapping (Jeff Patton
has an amazing book on it)

------
slicktux
I say we make a refrigerator library; then anyone can define a refrigerator
within the library; then we can call the function and apply it to out
arbitrary needs. #include <refrigerator.h>

~~~
venomsnake
Wrong. We need refrigeration factory that returns a class called
RealRefrigerator that extends AbstractRefrigerator and implementing
IRefrigerator, which then must be DI by configuring external XML (bonus points
if the xml itself is stored in the database, so no way to reach the config
with grep).

The outdated approach of if (food.canSpoil()) { refrigerator.put(food) } was
too burdensome and did not conform to all of the best practices.

------
mobiuscog
Amazing how many people try to create a specification without knowing the
problem.

A specification should be for a solution to a problem - "We need a way to keep
xxxxx cool". That problem defines what needs to go into the refrigerator from
the outset.

What's the actual problem space here ?

------
peter303
You can sometimes explain better by a set of examples rather than an explicit
categorical description. The base set of examples I started with is what my
mother put in her refrigerator.

------
1amzave
I'm reminded of an excellent quote from Bertrand Russell:

"Everything is vague to a degree you do not realize till you have tried to
make it precise."

------
pravj
cream, mayonnaise, ketchup, soda and PAPER, SNOW, A GHOST.

\- Joey Tribbiani, Friends episode 10.11

------
dmourati
The penguin line made me lol.

------
Jacoby6000
I'm going to repost something I had said in response to this article on
another site. I think it's an awesome example of what can happen when you
create a language with extensibility in mind.

\-------------------

Scala solves this problem really well with typeclasses.

You can define a typeclass like

    
    
        case class Refrigerated[T](thing: T) // this is just something holding things that have been refrigerated. 
        trait Refrigeratable[T] { // this is the typeclass
          def refrigerate(thing: T): Refrigerated[T]
        }
    

Now we have a refrigerated object that holds some object that's been
refrigerated, and it looks like I'm about to do some class composition, but
I'm not. Bear with me.

Now, we have some sort of data class

    
    
        case class Pillow(fluffiness: Int, warmness: Int)
    

Pretty straight forward, we now have a Pillow with measurable fluffiness and
warmth

Next, lets implement refrigerated for pillow.

    
    
        implicit val pillowRefrigerable: Refrigerable[Pillow] = new Refrigerable[Pillow] {
          def refrigerate(pillow: Pillow): Refrigerated[T] = 
            Refrigerated(pillow.copy(warmness = pillow.warmness / 2))
        }
    

So there's an implementation of Refrigerable for pillow. Refrigerating a
pillow just cuts the warmness in half.

So actually using the Refrigerable stuff. There's two ways to go about this.
One way is to just use the Refrigerable instance to refrigerate the pillow.

    
    
        def refrigeratePillow(pillow: Pillow): Refrigerated[Pillow] = pillowRefrigerable.refrigerate(pillow)
    

Nothing special there. You could basically do that in any language. So how
does scala do it better? Well, we can define a refrigerate method for anything
Refrigerable like this:

    
    
        def refrigerate[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]): Refrigerated[T] = 
          refrigerableInstance.refrigerate(thing)
    

Now this is really cool. Anything type that we have a Refrigerable instance
for, can be used as an argument for refrigerate. And we don't have to
explicitly state what Refrigerable instance we're using. Calling it looks like

    
    
        val refrigeratedThing = refrigerate(anythingWithARefrigerableInstanceHere)
    

Okay. We still haven't gained a whole lot. All we've done so far, is make it
so we don't have to explicitly state what Refrigerable to use. So let's go an
extra step. Let's make it so we just call refrigerate on the Object itself
rather than passing the object as an argument to a method. This is possible,
because scala let's us make extension methods for generics.

    
    
        implicit class RefrigerableOps[T](thing: T)(implicit refrigerableInstance: Refrigerable[T]) {
          def refrigerate: Refrigerated[T] = refrigerableInstance.refrigerate(thing)
        }
    

Okay, now this is really cool. We've defined a method for any type for which
we have Refrigerable in scope. This means we can now refrigerate our pillow
more easily:

    
    
        val refrigeratedPillow = myPillow.refrigerate
    

What?! That's great! And it gets better. Now that we've implemented this
boilerplate, giving other things this wonderful syntax is easy. Let's say I
want to refrigerate my cousin, because she's too hot.

    
    
        case class Cousin(hotness: Int)
        implicit val refrigerableCousin: Refrigerable[Cousin] = new Refrigerable[Cousin] {
          def refrigerate(cousin: Cousin) = 
            Refrigerated(cousin.copy(hotness = cousin.hotness - 1))
        }
    

Now we can make our cousin less hot! Great!

    
    
        val refrigeratedCousin = cousin.refrigerate
    
    

This is basically a good way to make things open to extension without
subclassing it's awesome!

You can even do more to simplify making the Refrigerable instances. You can
effectively make them one liners.

------
pvaldes
A porpoise

