2. Dharma

Every codebase has the file nobody wants to open. It started as one honest thing: a helper, a client, a service. Then it absorbed whatever was lying around: a little validation, a database call, some formatting, then a retry loop and a cache and a feature flag. Now it does everything, and it works, and the last three people who changed it broke something they never knew it touched. Nobody can say what it guarantees anymore, because it guarantees too much.

You know the file. You scheduled its last deploy for a Tuesday so you’d have the rest of the week to recover.

The Bhagavad Gita has a word for the thing that file lost. Arjuna is on a battlefield, refusing to fight, and Krishna’s long answer keeps returning to one idea: svadharma. Your own dharma. The work that is yours by your nature, not the work you could reach over and take because it looked easy from where you stood.

Dharma comes from a root, dhri, that means to hold, to bear, to keep together. A thing’s dharma is what it upholds by being itself. Sva is “own.” The claim that stops you comes twice in the text. K. T. Telang’s 1882 translation reads: “One’s own duty, though defective, is better than another’s duty well performed.”

Read that again as an engineer. It does not say do the work well. It says do your own work, even badly, before you do someone else’s well. The variable it optimizes is not competence but belonging: whose job this is.

We are trained to optimize the other variable. Do the thing well, wherever it is, whoever owns it. Be the engineer who fixes anything, who reaches into the module next door and cleans up a job that was never theirs. That instinct builds the file nobody wants to open.

The blind spot is that a component reaching past its purpose degrades the whole system even when it succeeds. It works, so nothing flags it. It just quietly becomes the place all the risk pools. When it finally fails, it takes down everything that had come to lean on the jobs it was never supposed to be doing.

There is a second half to the idea, and it is the sharper one. The Gita says the duty is fixed by svabhava, one’s own nature. It is not assigned from outside, and a component does not get its contract by writing a README any more than a person gets their dharma by announcing it. The contract is what the thing actually, observably guarantees, because that is what its callers have come to rest on. Hyrum Wright, an engineer at Google, turned this into a law: with enough users, every observable behavior of your system will be depended on by someone, no matter what you wrote in the docs.

The real contract is the behavior, not the signature. In March 2016 a developer unpublished an eleven-line npm package called left-pad, and Babel and React and thousands of builds around the world stopped working, because the whole ecosystem had been resting on those eleven lines without ever calling it a contract.

Knowing your real contract is only the setup. The point is what you do with it: hold your own, and refuse to reach for another’s.

The god object is that discipline inverted. It is para-dharma, another’s duty, well performed. It validates and it caches and it routes and it logs, each of those a job that belonged to some other part of the system, all of them done well enough that no test complains. The Gita has a word for what such a component becomes. Another’s duty, it says, is bhayavaha: fraught with fear. The word is exact. The god object is not broken. It is feared: the class with the comment that says do not touch, the deploy you move to a Tuesday.

The same verse has a harder line: better death in your own duty than survival in another’s. In code that is the difference between failing honestly and succeeding dishonestly. A function that hits a case it does not own can do one of two things. It can fail loud, within its contract, and let the caller handle what is not its job. Or it can guess, return a plausible wrong answer, and quietly do the neighbor’s work badly. The second one survives the code review. It is also the one that pages someone a week later, from a service three hops away that no one thought to look at, because it moved the failure out of sight. Better the honest death.

This is a discipline, not a rule against doing your job well. The defective in “one’s own duty, though defective” is about scope, not craft. Do your own job, and do it well.

A few boundaries, because a principle that claims to be universal is lying.

It is not an argument against refactoring. Moving a responsibility from one component to another is reassigning dharma on purpose, at design time, with the system’s consent: tests, review, a version bump. That is nothing like a component silently taking on another’s job at runtime.

Not quite Postel’s law, either. “Be liberal in what you accept” tells a component to tolerate messy input at its boundary, and that is still its own dharma: serve your callers reliably. Making a decision that belongs to another component is something else. The line is between tolerance and usurpation.

You can watch a language do exactly this. Go refuses to promise the iteration order of a map. The specification says it plainly: the order “is not specified and is not guaranteed to be the same from one iteration to the next.” The runtime randomizes it on purpose, so that no caller can quietly build a dependency on an order that was never part of the contract. That is a language holding its own line, refusing to let a habit harden into a promise it never made.

One boundary the mapping cannot cross, and it is worth naming rather than hiding. In the Gita, svadharma is entangled with varna, duty assigned by birth and caste. That is the opposite of a software contract, which is chosen, designed, and refactored when we decide to. The idea worth taking is the narrow one, that a thing has an intrinsic purpose and integrity lies in keeping it. Even the tradition treats svadharma as shifting with context and stage of life, so reading it as chosen rather than fixed is not a distortion of the idea. It is a refusal of its worst freight.

On the morning of August 1, 2012, a trading firm called Knight Capital pushed new code to its order-routing system, SMARS. The system ran on eight servers. A technician copied the new code to seven of them and missed the eighth.

The new code reused an old flag. Years earlier that same flag had switched on a function called Power Peg, code Knight had not used in roughly eight years and had left sitting in the codebase, dormant. On the seven updated servers the flag now meant something new. On the eighth, it still meant Power Peg, and Power Peg still knew how to send orders. It had just lost the part that counted whether enough had been sent.

When trading opened, the flag went high. The eighth server woke an eight-year-old job that was no longer anyone’s dharma and began firing orders into the market with nothing to stop it. It ran for about forty-five minutes. In that time it traded some three hundred and ninety-seven million shares the market had never asked for and lost the firm four hundred and forty million dollars. Its stock fell more than seventy percent, and Knight did not survive the year as itself.

The flag did not know it was doing the wrong job. A component cannot feel its dharma. It runs the job it is wired to run, and if a stale signal tells it to be something it stopped being eight years ago, it will be that, competently, until there is nothing left. The judgment has to live somewhere else. It lives with us: in the discipline of giving each part one job it can be trusted with, and never asking it to quietly become another.