When designing large, complex systems, you try to break things down into manageable chunks. For example, the bit that deals with user login or authentication. The payment bit. Something that needs to happen periodically. That sort of thing.

Before you know it, there are tens, or hundreds of chunks, each talking to each other or getting triggered when something happens. Problem is, how do these bits share data with each other. You can copy all the data between each chunk, but that’s not very time efficient. And if something goes wrong, you end up with a mess of inconsistent data everywhere.

So what bits of data do you keep in a shared place? What gets copied around from place to place? And what gets only used for that one function to get the job done? This is the job of software architects to sort out.

The author says the more copies of something you make, the more complexity and ‘state’ management you have to deal with. He’s right, but there are ways to mitigate the problem.

I think they just had some bad experiences with bad software and generalized it. If you just glue together separate components with separate data and configuration then you’re going to have a bad day.

TLDR: data is something you collect over time from users, so you shouldn’t let the contracts for it mindlessly drift, or you might render old data unusable. Keeping those contracts in one place helps keep them organized.

But that explanation sucks if you’re actually five, so I asked ChatGPT to do that explanation for you since that would be hard for me to do:

Here’s a super-simple, “explain it like I’m 5” version of what that idea is trying to say:

🧠 Imagine your toys

You have a bunch of toys in your room — cars, blocks, stuffed animals.

Now imagine this:

• You put some cars in the toybox.

• You leave other cars on the floor in another place.

• You keep some blocks in a bucket… and some blocks on the shelf.

• And every time you want a toy, you have to run to a different spot to find its matching pieces.

That would be really confusing and hard to play with, right? Because things are spread out in too many places for no good reason.

🚧 What the blog is really warning about

In software (computer programs), “state” is like where toys are stored — it’s important information the program keeps track of. For example, it could be “what level I’m on in a game” or “what’s in my cart when I shop online.”

The article says the biggest mistake in software architecture is:

Moving that important stuff around too much or putting it in too many places when you don’t need to.

That makes the program really hard to understand and work with, just like your toys would be if they were scattered all over the place. (programming.dev)

🎯 Why that matters

If the important stuff is all over the place:

• People get confused.

• It’s harder to fix mistakes.

• The program gets slower and more complicated for no reason.

So the lesson is:

👉 Keep the important information in simple, predictable places, and don’t spread it around unless you really need to. (programming.dev)