---
title: "The World Doesn't Ship With Source Code"
description: "Every system begins by taking apart a world nobody documented. What gets lost in that teardown doesn't just vanish from the software: it vanishes from life."
author: "Anderson Henrique"
date: "2026-08-08T00:00:00Z"
updated: "2026-08-13T11:35:33.588526Z"
category: "philosophy"
tags: ["Reverse Engineering","Social Engineering","James C. Scott","Data Modeling","Computer Science","Open Data","NTLabs"]
canonical: "https://www.ntlabs.dev/en/blog/mundo-nao-vem-com-codigo-fonte"
locale: "en"
---

*Reverse engineering, the residue a schema erases, and the thin border with social engineering.*

The first thing you learn when you try to audit the Brazilian state is that it doesn't ship with documentation. You download a public procurement dataset expecting to read data and discover you are reading ruins: fields whose meaning doesn't match the official dictionary, a free-text column where a standardized code should be and which, precisely for that reason, became the place where the real information hides. Negative values that can only be reversals, though no document says so. Dates that contradict each other because two different offices fill the same field under different rules, and neither knows about the other.

Nobody is lying. There is no conspiracy there. What exists is a system that has been running in production for decades, whose specification was never written, and which can only be understood through the behavior it emits. To audit the state, you first have to reverse engineer it.

It took me a while to notice that this wasn't the anomalous part of the work. It was the work. And that almost everything we do in software engineering is exactly this, except we rarely call it by its name.

## Every requirement is a teardown

We reserve the term "reverse engineering" for a narrow practice: take a binary with no source, observe its inputs and outputs, infer the logic, reimplement. It's what you do with a proprietary protocol, an undocumented driver, a file format that a dead company took with it.

Describe that same procedure without the word "binary" and you have described requirements gathering.

There is a system running in production. It goes by the name of registry office, emergency room, restaurant kitchen, public works department, Tuesday street market. It has no source code. Nobody holds its full specification, not even the people who operate it every day, because much of its logic was never verbalized: it was learned in the body, passed on by imitation, sedimented across decades of exceptions that happened to work. That system has hidden state, undocumented error handling, edge cases that only surface in December, and a generous amount of behavior its operators would deny if asked directly.

The computer scientist arrives, observes, interviews, measures, infers the rules from the behavior, and produces a reimplementation. A data model is a hypothesis about how the world works, written in a language that admits no ambiguity. A state diagram is a claim about which situations are allowed to exist in real life and which transitions between them are legitimate. A database constraint is an ontological prohibition: this cannot happen.

None of that is neutral, and none of it is "technical" in the harmless sense of the word. It is anthropology with execution privileges.

## What the teardown fails to capture

Every teardown is lossy. That is the part our profession prefers to treat as an implementation detail.

In *Seeing Like a State*, James C. Scott tells the story of eighteenth-century Prussian scientific forestry. The state needed to know how much timber it had, and the actual forest (with its mess of species, ages, undergrowth, fungi, animals, and people gathering firewood and herbs) was illegible to accounting. The solution was to make the forest legible: straight rows of a single species, uniform age, everything measurable, everything predictable. The model worked beautifully. The first rotation was a technical and fiscal success.

The second generation of trees fell sick. What the schema had discarded as noise (the understory, the species diversity, the soil fauna, the fungi doing the nutrient cycling) was precisely the infrastructure sustaining the productivity being counted. The loss never showed up in the report because, by definition, the report was made of the things that fit inside it. The Germans eventually had to coin a word for the outcome: *Waldsterben*, forest death.

Scott has a name for the knowledge that operation destroys: *mētis*. It is practical, local knowledge, acquired through experience, which cannot be codified without turning into something else. The fisherman's way of reading the tide. The exact moment the chef knows the meat has turned. The intuition of a clerk who looks at a case file and senses a document is missing before checking the list.

Every system we build runs the Prussian forest operation at a smaller scale. The form takes two surnames because the developer had two. The address field demands a street name and a number, which serves anyone living on a named street and erases from the map anyone living in alley four, house with no number, next to the church. The household registry has a "head of household" field, singular, and the actual domestic arrangement (grandmother, aunt, the neighbor who effectively raises the child) has nowhere to go. The scheduling system doesn't model the walk-in slot, which is how the queue actually works.

None of this is a bug. It is translation loss, and it is unavoidable. A map that lost nothing would be the size of the territory, as in Borges' tale, and would be useless for the same reason it would be perfect.

The problem isn't the loss. It's what happens after it.

## When the reimplementation becomes the original

In classical reverse engineering, you reimplement a system and the original keeps existing. If your reimplementation is wrong, it is the one that is wrong, and the binary stays there as a reference to check against.

In the reverse engineering of the social world it doesn't work that way. The reimplementation **replaces** the original. And from the moment it goes into production, it stops describing the world and starts prescribing it.

If the system won't take your address, you live nowhere. If there is no field for your family arrangement, your family doesn't exist for benefit purposes. If registration requires a document your reality doesn't produce, you are informal, and "informal" is just the name we give to whatever fell outside the schema. People then do what they have always done in the face of rigid systems: they deform themselves to fit. They invent a house number. They declare a guardian who isn't the real one. They learn which answer the form wants to hear.

The most beautiful and saddest Brazilian case of this is skin color. In 1976, the national household survey asked an open-ended question about it, and Brazilians answered with more than a hundred and thirty different terms: *morena*, *morena-clara*, *queimada de sol* (sunburnt), *canela* (cinnamon), *parda-escura*, *meio-branca* (half-white). It was a people describing itself in its own vocabulary, full of nuance, negotiation and history. The official schema accepts five categories. And today, fifty years later, the Brazilian racial debate, public policy, affirmative action, violence statistics, all of it happens inside those five boxes. The schema didn't describe the country's racial reality: it reorganized it. We came to think of ourselves in the grammar the form would accept.

This is why I insist that data modeling is not a software requirement. A schema is a proposal about which ways of existing will be recognized. Once it takes effect in a system that mediates access to healthcare, credit, benefits or justice, it stops being an opinion about the world and becomes a condition of the world. Like it or not, the computer scientist is in the business of deciding what part of a people survives translation.

## The other reverse engineering: the kind that takes people apart

There is an entire profession devoted to doing this to human beings, and it has a bad name for good reasons.

Social engineering, in the attacker's sense, is reverse engineering applied to human protocols. Kevin Mitnick built his reputation demonstrating that he almost never needed to break the cryptography: it was enough to take apart the social procedure surrounding it. He mapped the hierarchy (who is allowed to contradict whom), the time pressure (nobody audits carefully at six on a Friday), the fear of looking incompetent, the genuine desire to help a colleague. From those findings he built a reimplementation: a phone script that executed the human protocol with compiler-grade precision.

Notice the method is identical to ours. Observe behavior, infer the unwritten rules, find the edge case, exploit the gap between the official process and the real one. The difference between the social engineer and the requirements analyst is not the technique. It is what each does with the map.

And this is where it gets uncomfortable for anyone building product. The same study of cognitive bias that produces a gentle onboarding produces a dark pattern. The same fine reading of anxiety that yields a useful notification yields the trigger that blocks a subscription cancellation. Behavioral economics applied to design is reverse engineering of the human, and the border between serving and capturing is an ethical decision made by someone, not a property of the method. Anyone who works on interfaces works with the same lever as the attacker, only pointed the other way. Pretending otherwise is the most common form of professional naivety I know.

## Popper and the fence

There is still a third sense of social engineering, the oldest one: designing society.

Popper distinguished two ways of going about it. Utopian social engineering starts from a complete blueprint of the ideal society and rebuilds everything from it. Piecemeal social engineering changes one piece at a time, measures, corrects. Popper's objection to the first wasn't moral, it was epistemic: we don't know enough. The system is too complex, our hypotheses about it too fragile, and a total blueprint leaves no way to detect where it went wrong.

Translated into our vocabulary: utopian social engineering is a rewrite from scratch of a legacy system in production without reading the old code. Every developer with some mileage knows how that ends. Legacy code is ugly because it is full of fixes for cases you haven't hit yet. Each strange `if` is an incident somebody lived through. Rewriting without understanding means erasing a decade of empirical learning and reintroducing, one by one, every failure those lines were preventing.

It is Chesterton's fence, which is literally a reverse engineering argument: you find a fence in the middle of a field and see no use for it. The hasty answer is to tear it down. The mature answer is to leave it alone until you find out why someone built it.

Bring that into daily practice and the lesson is immediate. The side spreadsheet a department keeps "because the system can't do it" is not indiscipline: it is the specification nobody told you about. The workaround is the most honest bug report your architecture will ever receive. The informal process everyone uses, the one the manual forbids, exists because the formal process fails in some real and recurring case. If your migration erases the workaround without understanding the fence, you modernized nothing: you reintroduced the original problem behind a better front end.

## The objection I would raise myself

It would be easy to end here with the moral that we must "deeply understand before building". Except that conclusion is vague enough to be useless, and there are two serious objections to it.

The first is that total understanding is impossible, and the pursuit of it is an elegant form of paralysis. No amount of research captures *mētis*, by definition, because whatever is codifiable is no longer *mētis*. If the condition for building were understanding everything, nothing would ever be built, and inaction has victims too: the people who today have no system at all, and therefore no access to anything.

The second is the one I already raised: reverse engineering is the attacker's tool. Defending the practice in the abstract also defends whoever uses it to take people apart.

I accept both, and they change the thesis rather than defeat it. The goal is not to eliminate translation loss, which is constitutive of the act of modeling. The goal is to know **where** the loss sits and **who** pays for it. A documented loss is engineering. An invisible loss is ideology, and it starts operating as if it were the nature of things. The difference between the engineer and the ideologue is not the size of the error: it is whether they left a way to find it.

## The craft, then

A few things follow from all this for people who ship real software, with deadlines and budgets.

Observe behavior, not discourse. What people say they do is the manual; what they do is the binary. Requirements gathered by interview alone are third-party documentation, and you already know what that is worth.

Treat the exception as specification. Every side spreadsheet, every notebook under the counter, every comments field used as a database is a capability the world demands and your schema refused.

Record what you threw away. We adopted ADRs for architecture decisions and almost never record the most consequential decision of all: what this model refuses to represent, and who is left out when it refuses. A list of known losses is worth more than a pretty diagram, because it is what lets you audit the damage later.

Build systems that can be taken apart. If a system mediates rights, it has to be reversible by the people who depend on it: readable logs, explainable decisions, exportable data, auditable criteria. Explainability is not academic decoration, it is institutionalized reverse engineering, offered by the system instead of wrenched out of it. That is why a black box in public decision-making is not a performance problem: it is a political decision about who gets to contest what.

## The right to take it apart

Which brings me to the point I consider most important, and which reaches past engineering.

Our legislation already recognizes pieces of this, without using the word. Brazil's Access to Information Act exists so that citizens can examine how the state works. Our data protection law provides for requesting review of decisions made solely by automated means, and information about the criteria used, subject to the trade secret limits the law itself sets. These are, at bottom, reverse engineering provisions: guarantees that systems deciding your life can be opened and questioned.

Reducing that to compliance misses what is at stake. A people whose relations are mediated by systems it cannot take apart is not a people poorly served by technology: it is a people that has lost access to the grammar of its own common life. The rules governing who gets a benefit, who moves up the surgery queue, who is denied credit, who is flagged as suspicious, those rules were already written somewhere, by someone, out of some reading of who we are. If they cannot be read back, they have stopped being collective decisions and become natural facts. And you don't argue with natural facts: you only suffer them.

That is why I think of reverse engineering as a civic competence, not a niche technique for people who enjoy taking binaries apart. It is the gesture of refusing to let a system be the world. It is the difference between inhabiting a reality and being executed by one.

The world doesn't ship with source code. With every schema we write, we hand people a version of it to live inside. The least we owe them is to leave the lid open.

---

*This piece is part of our reflection on **transparent engineering** at NTLabs: how we build, what we decide to represent, and what we acknowledge we are leaving out.*