All Models Are Wrong, But Some Are Useful

To solve a problem, we need to understand it. And this is true not only for software engineering. When we understand the aspects of a problem well enough to start thinking about a solution, it means we have already created a mental model of it in our heads.

What is a mental model?

A mental model is an internal cognitive representation of how something works in the real world.

Every model we create has a few main characteristics:

• simplification — it compresses complex systems into manageable concepts.
• incompleteness — it does not contain every detail or represent reality completely accurately, but it remains useful for everyday problem-solving.
• evolvability — it changes and adapts over time as we gain new experiences and correct our assumptions.

The same principles apply when we turn our understanding of a problem into models that become part of the software we design. The model we create in software is not a copy of the real world. It is another representation of our understanding, created for a particular purpose.

Simplification

A model contains the information relevant to the problem or decision we are trying to address. But a good model simplifies this information as much as possible.

Using our training center as an example, take a look at a trainer. If we want to model a trainer to solve the problem of skills assessment, the model could contain information such as years of experience, conducted trainings, certificates, a list of publications, conference talks, survey results, and other information related to their skills.

Yet all this information can be reduced to the details we actually need. A list of publications may be represented simply as a list of titles with the number of people who read each one. Content, publication dates, comments, and other details may be skipped because they are irrelevant to the problem we are solving.

And this is fine. Thanks to that simplification, we are not overwhelmed by data that we do not need to solve the problem.

Incompleteness

A model does not contain every characteristic of the things it represents.

Let's take another look at our trainer, with their experience and skills. But a trainer is much more than a set of skills. For example, I'm a trainer, and beyond the data I listed above, I also live somewhere, have a family, have hobbies, and much more. Should this be part of the model simply because this information is also about the trainer?

Definitely not, if the problem we are solving is their skills assessment. Such information would not only be useless. It would also introduce unnecessary noise, making it more difficult to understand the business later.

On the other hand, if you are interested in how to implement various roles of a person while maintaining their identity, I encourage you to explore the articles about archetypes.

Evolvability

The set of problems we need to tackle is not written in stone. New requirements appear, new scenarios emerge, and corner cases are discovered. To support them, the model may need to evolve as well.

Let's get back to our trainer and their skills assessment. Imagine that, after the system has been in use for some time, the business decides that it is not enough to assess whether a trainer has the required skills. They also want to determine whether the trainer is suitable for a particular type of training delivery - for example, whether they have experience delivering remote training to large groups.

This information was not part of the original model because there was no reason to include it. The problem we were solving did not require it.

Once the problem changes, however, the model needs to change with it. We may need to introduce information about remote-training experience, the size of groups previously handled, or other characteristics relevant to this new assessment.

Would it make sense to add this information from the beginning? No. It would create unnecessary noise, and we would never have a guarantee that we could foresee the future correctly. Some information only becomes relevant much later, after our model has already been created and the system has evolved.

All models are wrong

"All models are wrong, but some are useful" is a famous aphorism coined by the British statistician George Box in 1976.

When you look at the characteristics of a model, the first part of the sentence is not only obvious but makes perfect sense. Simplification and incompleteness make a model different from the reality it represents. But this is not a flaw. It is a benefit that allows us to understand a problem and its solution much faster and more easily. We are not overwhelmed by additional information that is useless in the context of the problem we are trying to solve.

The second part - "but some are useful" - is where our responsibility as system designers begins. It is easy to model reality, simplify concepts, and reduce information. But remember: a good model is created to solve a problem.

It needs to contain all the information we need to understand both the problem and its solution. At the same time, it should not contain additional information that is irrelevant to the problem and could mislead us or distract us from what actually matters.

That is what makes a model useful.

Summary

A model is not a copy of reality. It is a deliberate simplification created for a purpose. It is incomplete because it does not need to represent everything. It evolves because the problems we solve evolve.

The challenge in software engineering is therefore not to create a model that represents reality perfectly. It is to create a model that represents the right parts of reality for the problem we are trying to solve.