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.

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.

"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.

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?

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" :/

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.

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.

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

https://www.youtube.com/watch?v=PZbqAMEwtOE

"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.

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."

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

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-...

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.)

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.

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>

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 ?

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.

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."

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

- Joey Tribbiani, Friends episode 10.11

The penguin line made me lol.

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.

A porpoise

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.

The article is on the difficulty of writing specifications. The fridge is a metaphor. Your insight amounts to “we can always assume that the specification has already been written and correctly implemented on the other side of the interface”.

This remark has a place in the discussion, but not the one you probably think.

So one only puts labelled packaged things in the refrigerator? I was recently thinking about the phenomenon of packaging but this takes it to the next level. I'm not sure if it feels ultra-modern or dystopian.

    scan label
       if (grep "keep refridgerated after opening") AND (status OPEN) then
          store in fridge else
       ask

I guess I need to put best before dates on all my fresh produce then. Otherwise how will I know whether I need to refrigerate my head of cabbage after opening it, and whether it is still edible or not?

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.

We cannot always change the real world to adopt to our spec needs -- e.g. make things that need refrigerated communicate that need.

There are literary thousands of things we refrigerate that don't come in packages with neat "refrigirate" labels.

Although work is then required to package items appropriately, rather than the refrigerator automatically knowing what to do with items.

(More on-topic,) I think the point presented still holds. It's not possible to make an air-tight spec for absolutely everything.