Focus on the data first
►► Audio, Video, and Transcript available: https://lispcast.com/focus-on-the-dat...
►► Subscribe on iTunes: https://itunes.apple.com/us/podcast/t...
What should we design first to make sure our software will last without having to constantly rework our code? We should focus on the data first because it is the most timeless.
Transcript
How do we ensure that when we write software it will last as long as possible, that we won't have to keep updating it, rewriting it and revisiting it all the time? My name is Eric Normand and these are my thoughts on #functionalprogramming.
This is a very common problem where we write some #software. Either we just live with the problems with it, because we don't have time or a chance to go back over it and fix it, or we're constantly fixing it because there's just something messy about it. It's not right. We can't find a way to clean it up.
In my theory of functional programming which divides things up between data, calculations and actions, in that theory, it's very clear where you should start. As you move from the top, actions through calculations down to data, data is actually the most timeless thing.
Actions, obviously by definition, they depend on the time. They depend on when and how many times they are run. Calculations don't depend on when or how many times they're run. They're timeless, except they're opaque and they're in code.
You may want to switch #functionallanguages in the future. There is always this possibility that that code will break somehow, that you won't be able to run it anymore. The data is much more timeless. The only risk is that the data format becomes impossible to read or the data format becomes unclear what it's for.
That's why I say we should start with the data. It is the thing that is inherently the most timeless. If you start with the data and start designing the data, you can increase the chances that it will survive for the long-term.
Meaning, you design it, you think about the names of the parts of it. You think about how to communicate or making it clear when you're out putting this data, what things mean and what they are used for. That is something that I've learned over the years that the data is the thing that is the most valuable. Once you know you're going to record some events that's timely.
Some event happens like the user clicks a button, you're reading a sensor, or you're getting an image from a camera. Once you capture that, you can't go back in time and capture it again. You want to capture it in a high fidelity format for your purposes.
It's very important to make sure that that data is future proof. As things change that you can still use that thing. That is never going to change. You can make a new piece of data from it that might be more future proof. That piece of data itself is inert. It's done. It's dead on the disk.
The way you keep it alive is by writing code that knows how to interpret it. That data is going to last way longer than any code you write. It could be in a database. There's just storing all these records for everybody for all time. Basically as long as your company is around and you hope that that lasts a while.
Data is where it's at. That's where we need to start. How do we design the data? What is important about the data? What do we want to capture? The first thing is that you want it to be at least somewhat human readable. Doesn't mean that a human is going to read it and interpret it themselves. It means that someone in the future can read it and write a program to interpret it.
It needs to be clear what the pieces are. You would like the names to be timeless. One problem that we have a lot in software is when we write a name down for something. It is unclear. We write the name down in code. Then we'll later on change the code to do something else with that same name.
It might not seem like a problem at the time but often it is. You have something like you say, "First name is a string." You just treat it like a string. Later you say, "We weren't actually strict enough. First name needs to be a non-empty string with no spaces at the beginning and end of the string."
Now, you're more restrictive. You may have first things with empty strings in them from before you started restricting that. You've actually changed the meaning of first name in your code. You can't read those old records. They're not readable before.
What's worse is if this is part of an API, clients of this API might not change. They might not change in lockstep with your changes. They have data that they've been processing through this API. Now, it's not going to go through.