There is a section of every codebase — and every engineer knows exactly where it is — that nobody wants to touch.
Not because it’s complex. Because of what touching it might disturb. It has layers. The layers have layers. Somewhere in there is a decision made under deadline pressure in 2021 that has been silently compounding ever since. The code works. Probably. Don’t look too closely.
This is technical debt. Everyone agrees on the definition: shortcuts taken now that must be paid later, with interest.
But the framing of “debt” is actually misleading. Debt has a lender. Debt has a contract. Debt can be negotiated, deferred, sometimes forgiven. Technical debt has none of those properties.
The better word is karma.
What Karma Actually Means
Before the word became diluted into “what goes around comes around” bumper sticker philosophy, karma had a precise technical definition in Indian thought.
Karma (कर्म) means action. In Vedic philosophy, it is the law that every intentional action produces a consequence — not as divine punishment or reward, but as a natural, mechanistic result. The consequence is encoded into the action itself, the way a seed encodes the tree.
The Bhagavad Gita, chapter 4, verse 17:
कर्मणो ह्यपि बोद्धव्यं बोद्धव्यं च विकर्मणः। अकर्मणश्च बोद्धव्यं गहना कर्मणो गतिः॥
The nature of action must be understood. The nature of wrong action must be understood. And the nature of inaction must also be understood. The way of karma is profound.
Three types of action: karma (right action), vikarma (wrong action), akarma (apparent inaction that still produces consequence). All three produce results. There is no neutral ground. Every engineering decision — including the decision to not decide — leaves an imprint.
This is a more accurate description of technical debt than the financial metaphor.
How Code Karma Accumulates
Consider the classic sequence.
Week 1. You’re building a new feature under deadline. The clean solution would take two weeks. You have five days. You hardcode a configuration value that should be dynamic. You tell yourself you’ll fix it after the release.
This is vikarma. Wrong action, knowingly taken. The consequence is encoded.
Week 3. The feature ships. The hardcoded value causes an edge case in production. A colleague fixes it in the quickest way available — adds an if-statement around the hardcode. The intent is to “fix it properly later.”
The karmic debt compounds. Two engineers now know there’s a problem but have deferred it twice.
Month 4. A new engineer joins. They need to add behavior near that if-statement. They can’t understand why the condition exists — there’s no comment, no ticket, no git blame message that explains the original constraint. They add another if-statement to work around the first.
The debt has now acquired interest. The original consequence has produced secondary consequences. The code has a dharma now — its own nature, its own karma that will continue producing consequences independent of anyone’s intentions.
Year 2. The module has seven nested conditionals, three of which exist because of that original hardcoded value. Refactoring it requires understanding the entire history. No one does. The code becomes load-bearing in ways no one fully understands.
This is not “debt” in the financial sense. There is no lender. There is no contract. The consequences arrived mechanically from the actions, exactly the way karma works.
The Three Types of Code Karma
Mapping the Gita’s framework directly:
Karma (Right Action) — decisions made with full understanding of consequences, including long-term ones. Writing the test before the feature. Documenting the non-obvious constraint. Choosing the less convenient but more maintainable solution. This produces consequences too — mostly good ones — but they are considered and accepted.
Vikarma (Wrong Action) — shortcuts taken with awareness that they’re shortcuts. “I’ll fix this after the release” is vikarma. The engineer knows. The consequence is encoded anyway. The difference from ignorance is that vikarma is knowingly incurred.
Akarma (Apparent Inaction) — the decision not to refactor the thing you see is wrong. The choice to not document the edge case you just discovered. The failure to raise the design concern in the review. These are not neutral. They are choices that produce consequences. The engineer who doesn’t speak up about a flawed architecture has still taken an action — they have chosen to let the karma accumulate.
The Gita’s point about akarma is its most uncomfortable claim: there is no such thing as neutral inaction. Not deciding is a decision. Not fixing is a choice. The consequence arrives regardless.
Why the Gita’s Solution Works
The Gita’s answer to karma is not “avoid action.” That’s impossible — the engineer must ship, must decide, must move forward.
The answer is nishkama karma: action without attachment to the fruit.
कर्मण्येवाधिकारस्ते मा फलेषु कदाचन। मा कर्मफलहेतुर्भूर्मा ते सङ्गोऽस्त्वकर्मणि॥
You have a right to action, not to its fruits. Let not the fruit of action be your motive. And do not be attached to inaction. — Bhagavad Gita 2.47
Applied to technical debt: this is the instruction to refactor without ego.
The debt was incurred. The consequences are real. The question is whether the engineer who refactors it is doing so cleanly — focused on the code’s eventual state, the system’s health — or contaminated by anxiety about who incurred the debt, resentment about the mess, attachment to how the refactor reflects on their reputation.
Nishkama karma in code:
- You refactor the module because it needs refactoring, not because you want the git blame to show your name on clean lines
- You write the test because the system needs it, not to demonstrate your testing discipline in the PR review
- You document the constraint because the next engineer needs it, not because you want to be seen as thorough
Action performed without attachment to outcome produces cleaner karma. It also, pragmatically, produces better code — because the engineer focused on the system’s health rather than their optics will make different trade-offs.
The Karmic Weight of the Rewrite
Every engineer who has inherited a difficult codebase has had the thought: we should just rewrite it.
The Gita would call this a misunderstanding of karma’s nature.
A rewrite is not an escape from the karma of the old system. The shortcuts that produced the original debt were not random — they reflected constraints that still exist: deadline pressure, incomplete requirements, knowledge gaps, organizational dynamics. A rewrite under the same conditions produces the same kind of karma. Different code, same pattern.
Joel Spolsky wrote about this in 2000: rewriting from scratch is almost always the wrong decision, because you throw away the accumulated understanding encoded in the original code — including the understanding of why the bad decisions were made, what they were working around.
The Gita’s framing adds something Spolsky’s doesn’t: the rewrite carries its own karma. The decision to rewrite, made with full understanding of the tradeoffs, with proper accounting of what will be lost, is a different action than the decision to rewrite made in frustration and impatience. The first might produce good consequences. The second almost certainly produces the same debt in new clothes.
Paying It Back — The Bhishma Method
Bhishma, in the Mahabharata, spent his entire adult life carrying a vow he made impulsively in his youth — the vow of celibacy that gave him his name. The vow produced consequences he could not escape. He could not become king. He could not leave Hastinapura. He witnessed atrocities he opposed but could not stop, because his own karma had constrained his options.
At the end, on his bed of arrows, he did not curse the vow. He spent his remaining time transmitting knowledge. The Bhishma Parva is the most concentrated repository of dharmic teaching in the Mahabharata. He used the position his karma had put him in to do as much right action as that position allowed.
This is the engineering model for inheriting bad code.
You didn’t incur the debt. You cannot undo the history. The karma is yours now, by inheritance. The question is what right action looks like from within the constraints it has created.
It looks like:
- Mapping the debt honestly before promising to fix it
- Fixing what the current sprint allows, not what ego demands
- Documenting what you understand so the next inheritor has more information than you did
- Not adding new vikarma while paying back the old
The debt is paid incrementally, not in one righteous rewrite. The karma settles through sustained right action, not a single dramatic act.
The Test That Distinguishes Good Karma From Vikarma
Before every engineering shortcut, one question. Not “will this work?” — the shortcut usually works. Not “is this ideal?” — obviously not, that’s why it’s a shortcut.
The question is: am I comfortable with future engineers reading this and understanding why I made this choice?
If yes — and if the constraint that required the shortcut is documented — this is karma, not vikarma. Right action under real constraints, acknowledged clearly.
If the answer is “I hope nobody looks at this” — that’s the karmic signature of vikarma. The guilt is the recognition that a consequence has been deferred, not avoided.
The Gita doesn’t promise that right action is always convenient or that vikarma is always punished quickly. It promises that the nature of action is mechanistic. The consequence arrives.
Build accordingly.
Written in Varanasi. The bhashya on karma that informs this is mostly Adi Shankaracharya’s commentary on the Gita, with some Madhvacharya for the mechanistic interpretation of consequence. Both agree on the basic physics.