We make information systems

I often have to remind myself that we make information systems when we are programming for a business. My natural tendency, due to years of education, is to begin by creating a simulation. But this is not what we need to do. Instead of simulating a shopper going through a store, we need to model the information transfers that were captured in the pre-digital information system of pen-and-paper inventory and order management.

Transcript

Eric Normand: We make information systems, and we shouldn't forget that. Hi, my name is Eric Normand. I help people thrive with functional programming. This is going to be one of those thought pieces, I guess, less of a tutorial.

I want to talk about what I was taught in school, what I see other people being taught, and my opinions on some of that. Often, when we're dealing with modeling a problem, we're taught to think about the actors in the system. These are the entities that act out the drama in the situation, in the simulation.

The example would be if you're buying things at a grocery store. There's the shopper. There's the apples, oranges, and bread that they're buying. Those we're taught to model in our code. You would make a shopper class. You would make a product class. Then you'd subclass it with orange, apple, and bread classes.

Then you would have some kind of methods on it. If you have something like the shopper buys a bread as a scenario, a use case that you have to implement, you have to decide, but you might put the method buy on the bread, or you might put it on the shopper. It depends.

That's where the debate is, "Where do you put it? Who's doing the shop? Who's the noun? Who's the verb? Who's the subject? Who's the object?" I've done those systems. I've done them as assignments. Unfortunately, I've done it so many times that it's the way I think when I'm working on side projects and things.

That's the real issue. I'm struggling to get to the meat of this and not be condescending, because I do think that this is a problem with the way we're taught and the way the examples are in our books, the examples our professors use.

We're not modeling. When you get to the real world and you're working on a business, let's say, you're working on a supermarket, and they want you to code up their system. You're not actually going to be coding up a simulation between a shopper and a broccoli.

That's not what is happening. What you should be modeling, what you should be implementing is the information system of that store. If it's a successful store already, like before they're digitized, before they're computerized, they've probably already got information systems in place, probably.

It might be paper and pencil. It might be in somebody's head, but it's a system already where they're writing down the inventory at the end of the day. They keep track of their sales. They keep track how much money they think they should have in their cash registers. Maybe, they're figuring out how many tomatoes they need to buy the next time they order tomatoes. That is what we're modeling.

We're not modeling the situation of the shopper picking up the broccoli and carrying it to the checkout counter. That almost doesn't even need to be modeled unless you're in a totally virtual environment. We'll get to that. We're modeling the information system. We're modeling the transactions of money and product.

There's shippers coming in, bringing truckloads of food. We're tracking that. We're tracking how long it takes for that food to leave the shelves. We're tracking how much storage space we need to keep our inventory. We're tracking all the employees and how much we have to pay them and how much profit we're making, how much revenue.

These are the things that are part of the information system. They're left out typically when we are taught to think about a problem in software. I just want to reiterate that. We model the information systems, and we often forget that. We treat these exercises as telling us something about how supermarkets work when that's not what's going on.

I don't know if I have anything more to say about this except that I do believe that the way that I've been teaching functional thinking, which is to divide things into actions, calculations, and data, can help you see that more clearly.

If you see where is data being stored or sent from one place to another and be captured by devices, you're thinking about calculations, what computations are being done. Then when you think about actions, especially in terms of essential actions, things that have to happen, not like storing stuff in a global variable, that doesn't have to happen even though that is an action.

Say, making a particular computerized order to another fulfillment center, that is an action that you want to happen. You can't get around it. What are those actions that are taking place?

By doing that, you get a little bit closer to figuring out the pieces that you need to implement in your system. It's not enough. That's just the start of the analysis, but it's somewhat closer than what I consider the...

I'm trying to be so nice here, so forgive me. [laughs] I would not normally be so generous with this stuff. If you caught me alone and bought me a drink or something, I probably would not be so generous.

We're taught to model things in terms of nouns and verbs or in terms of type hierarchies, you might say. Inheritance are hierarchies. We're not modeling those aspects of the world. We're modeling the information system.

Another example — I literally had this exercise in my school. We were supposed to model a university registration system. You have a student class. You have a course class. The whole exercise was about figuring out where to put the methods and how to make it so that the student knows what courses it's registered for, and the course knows what students it's registered for.

The state of the course has to be maintained in sync with the state of all the students. The problem is, it's the same fallacy. What you're simulating is students registering themselves into courses instead of simulating or modeling the registration book or the computer system that exists at the university. That is what you should be doing.

Basically, you just need a single table that joins the students, the student ID with the course ID, and to put some kind of object-oriented front on top of that, like it's some kind of simulation. Like the student calls register on the course, and it passes itself as an argument. It's kind of a farce.

Just don't forget, we're modeling the information systems, not this interplay of different entities. I hope this wasn't too much of a downer.

If you want to listen to more episodes, you can go to lispcast.com/podcast. You'll see a list of all the past, present, and future, and multiverse episodes. They each have audio, video, and text transcripts. You can pick the way you like to consume the content.

There's also links to subscribe and how to find me on social media including email, Twitter, and LinkedIn.

I love to get into discussions, so fire away those discussions, comments, questions, complaints, anything. We'll talk about it. Awesome. Rock on.