In software management, "technical debt" is often discussed as an abstract concept. However, a significant portion of that debt stems from a specific source: impossible states. Algebraic Data Types (ADTs) are a disciplined way of defining what is allowed in a system so that invalid configurations simply cannot exist.
The problem: systems that allow nonsense
Most software today is built using "loose" data modeling. Consider a standard user profile:
- is_logged_in (True/False)
- is_admin (True/False)
On the surface, this is simple. But this design allows for a logical contradiction: a user who is not logged in but is marked as an admin.
It's the digital equivalent of saying someone is not in the building, yet they are currently in the executive boardroom. It shouldn't be possible, yet the code allows it. When a system permits these "impossible states," engineers must write defensive checks (if/else statements) everywhere to prevent bugs. Over time, this results in:
- Increased testing overhead.
- Slower development cycles.
- Higher maintenance costs.
- Subtle, hard-to-track production incidents.
The Solution: Structural Integrity
Instead of using various "flags" to describe a user, an ADT approach defines the user as exactly one of a few specific roles:
- Anonymous (No extra data)
- LoggedIn (Contains a username and specific permissions)
In this model, there is no physical way to be "Anonymous" and an "Admin" simultaneously. The system's architecture makes the error impossible to code.
Three Business Consequences
1. Reliable Production Environments Bugs are often the result of "edge cases" where data ends up in a combination the developer didn't foresee. ADTs eliminate these edge cases by design. The system doesn't just catch errors; it refuses to represent them.
2. Safer, Faster Iteration
When you need to change the system—for example, adding a new "Guest" tier—the compiler acts as an automated auditor. It forces the developer to update every single part of the application that handles users. Nothing is left to memory, and nothing breaks silently.
3. Lower Cognitive Load
Engineers no longer need to remember complex hidden rules (e.g., "The admin flag only counts if the login flag is also true"). The rules are encoded into the structure of the data itself. This significantly reduces onboarding time for new hires and lowers long-term maintenance costs.
The AI Advantage
As more organizations look toward AI-assisted coding, data structure becomes even more critical. AI tools are significantly more accurate when the "possibility space" of a system is narrow and explicit.
If a system clearly defines that a user is either Anonymous or LoggedIn, the AI doesn't have to guess which combinations of flags are valid. This leads to fewer "hallucinations" in the code and more reliable automated suggestions.
Summary: Risk Control Through Design
Think of ADTs like internal accounting controls. You can either spend resources training people not to make illegal entries, or you can design the ledger so that illegal entries cannot be typed in the first place.
One approach relies on constant human vigilance; the other relies on structure. Algebraic Data Types provide a structural reduction in risk, making your software more predictable, your developers more efficient, and your systems more resilient to change.
Top comments (1)
I asked ChatGPT to explain it like I'm 5.
Imagine you have a toy box.
Inside the box, you can put either:
• a teddy bear
• or a robot
That’s it. Only those two things.
Now imagine someone instead says:
“This toy has two switches: – is_teddy
– is_robot”
And you can turn them on or off however you like.
So now you can accidentally create:
• is_teddy = true
• is_robot = true
Which means… your toy is both a teddy and a robot.
Or:
• is_teddy = false
• is_robot = false
Which means… it’s nothing.
That’s silly. But the system allows it.
Algebraic Data Types are just a fancy name for saying:
“Stop using random switches. Just say what the thing actually is.”
So instead of two switches, you say:
This toy is either: • Teddy
or
• Robot
You physically cannot create a “nothing” toy.
You cannot create a “teddy robot monster.”
The box refuses it.
That’s the whole idea.
Now why is this powerful?
Because if your software can only create real, sensible things, you don’t have to constantly check for nonsense later.
No “Wait… what if it’s both?” No “Wait… what if it’s neither?”
You removed the possibility of stupid combinations.
So in adult terms: Instead of letting your system store nonsense and hoping nobody trips over it, you design it so nonsense cannot exist.
That’s it.
It’s not magic. It’s just telling the truth about what things are.