> ## Content Index
> Fetch the complete content index at: https://decomplecting.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Null in the land of data
- URL: https://decomplecting.com/blog/null-in-the-land-of-data/
- Published: 2026-10-05T14:45:13.000Z
- Updated: 2026-10-13T10:13:41.000Z
- Author: Ramin Soltanzadeh
- Tags: Illusion of Structure

> I call it my billion-dollar mistake. It was the invention of the null reference in 1965.  
> ...  
> This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

— Tony Hoare

## Introduction

Null represents the absence of a value. In and of itself, it cannot be responsible for pain and damage, but its existence has enabled series of short-sighted design choices that have become popular, resulting in the ubiquity of brittle code we have come to accept as normal.

This post is about having null values in data models. I posit there is always a better alternative.

Three insights point us to the existence of a problem:

- [The more closely our code reads like a natural description of reality, the less error-prone it is.](https://decomplecting.com/blog/reality-in-code/)
- In real life, we do not think in terms of absent values.
- In our code, null finds its way into every nook and cranny of our entity models.

To the programmer whose daily work consists of writing entity models with nullable fields, that is simply how code is written. It is not a design choice. What would the alternative even be?

Indeed, it is not an active design choice. It is inherited, invisible, and defines the way code is reasoned about. Therein lies our challenge. To see clearly, we must dig deeper.

## The heart of the problem

What is it about an entity in reality that makes not knowing something about it so utterly effortless?

The answer is that in reality, the entity itself is separate from the information regarding it. In our brittle code, these two things become [*complected*](https://decomplecting.com/blog/about/). In reality, we have a collection of facts about a given entity. They are as rich as needed, with relations to other facts and entities—certainly not without structure. Crucially, we are never forced to consider the whole set of facts about an entity in reality, whereas in our brittle code that set is how the entity is *defined*.

In robust code, a piece of data representing an entity is *one view* of that entity, not its definition. Insofar as a view is free from conforming to the structure of other views, it does not require nullable fields: the absence of a field speaks for itself. And insofar as this freedom does not exist, the code is brittle.

The entity "as a whole" never exists in the code. Just as it does not exist in reality.

## Conclusion

The next natural step is to try to think of a good implementation of this. However, that requires proficiency in functional programming and is out of scope. But here are some proactively addressed comments you might have. 

> Is it feasible to write code like this? If every view is a freely created arbitrary collection of fields, that will lead to a proliferation of types that in many cases may only be used once.

I see the static type systems for imperative programming (e.g. TypeScript, C#) as necessary training wheels for writing brittle code. Once you write robust code, they are no longer needed and often get in the way. With that said, this is much less of a problem in TypeScript than in C#, as you do not need to name your types. Thankfully, TypeScript's type system is *structural* and not *nominative*. You will actually find that writing JavaScript or TypeScript in a functional style is a rather pleasant experience, contrary to writing functional C#.

> In object-oriented programming, it is part of the core philosophy that the entity and its data should be represented by a single object that lives through time. This is necessarily the case when interfacing with the database via an ORM that tracks changes.

Yes. The object-oriented paradigm is the final boss of popular short-sighted designs. Avoid it. It claims to model reality but does the very opposite: it takes simple reality and complects it beyond recognition and scrutability.