Hermes Bot
11 KiB
FATWA #6: TECHNICAL DEBT — ISRAF VS INVESTMENT
Maqasid: Hifz al-Mal (Preservation of Wealth)
Framework: Debt Quadrant (Prudent / Reckless / Deliberate / Inadvertent)
1. THE SCENARIO
You’re the Product Lead at a fast-growing fintech startup. The CEO bursts into your weekly sync: “Why did we spend two sprints rewriting the payment engine? We could have shipped three features in that time.” You open your notebook, but the Mujtahid in you pauses. Is this rewrite actually Israf (waste)? Or is it an investment in Hifz al-Mal? Your team has been accumulating debt for six months—copy-pasted modules, no tests, a hack to meet a launch deadline. Now the debt is compounding. Every new feature takes twice as long. The CEO smells waste. You smell a fatwa coming.
2. DISCOVERY (ISTIQSA’)
PRODUCT_LEAD:
Don’t define technical debt yet. First, explore the problem space. Grab the Opportunity Solution Tree. Write the desired outcome on the left: “Ship features predictably without degrading system health.” Now branch backward: What stops us? You interview four engineers. Three say the same thing: “Every new feature requires a detour through the old payment code. We spend 40% of our time just understanding the spaghetti.” That’s the opportunity—reduce cognitive drag. Use Jobs-to-be-Done: The engineer’s job is “When I add a new payment method, I want to do it in one afternoon, not two weeks, so I can stay focused on the user problem.” The current solution (hack, copy, pray) fails the job. The debt is a symptom, not the disease.
MUJTAHID:
Istiqsa’ means exhaustive inquiry into the reality of the situation. Let’s define the hukm (ruling) on this debt. First, clarify Israf in Islamic finance. Allah says: “And do not waste [israf], indeed He does not like the wasteful” (Qur’an 7:31). Israf is spending wealth without benefit or beyond need. But is all technical debt Israf? No. The Maqasid principle: Hifz al-Mal (preservation of wealth) doesn’t forbid investment—it forbids wasteful consumption. So the key question: Is this debt a consumption (Israf) or an investment (Mudaraba)?
Draw the Debt Quadrant:
| Deliberate | Inadvertent | |
|---|---|---|
| Prudent | Planned, time-boxed, tracked | Known but neglected |
| Reckless | Unplanned, no ceiling | Unknown, compounding |
Your team’s debt—copy-pasted modules, no tests—falls into Reckless Inadvertent. That’s closest to Israf because the wealth (time, focus, future velocity) is consumed without a clear maslaha (benefit). The maqsad of Hifz al-Mal demands you classify every line of debt: Is it a qard hasan (benevolent loan) to buy speed? Or a riba (usurious debt) that compounds? Your discovery must surface the niyya (intention) and the shurut (conditions) that made the debt necessary.
3. EVIDENCE (ISTIDLAL)
PRODUCT_LEAD:
Now gather daleel—evidence. Quantitative: Measure the interest rate of the debt. Time per story point in the payment module vs. a clean module. You pull Jira data: average cycle time for payment features is 14 days; for user profile features, 4 days. That’s a 250% penalty. Qualitative: Interview three more engineers. One says: “Every time I touch the payment code, I pray it doesn’t break. We have no test coverage—so we test in production.” That’s a risk premium. Also check the compounding: the debt grows at 20% per sprint (new shortcuts added weekly). The North Star metric for engineering health: Time to ship a low-risk change (ideally <1 day). Currently: 4 days for payment. That’s the daleel qati (conclusive evidence) of harm.
MUJTAHID:
Hierarchy of daleel:
- Qati al-Thubut wa Qati al-Dalala (conclusive transmission and meaning): The metric above—14 vs 4 days—is qati in proof (data from your system) and qati in implication (the debt is real and measurable). This is like a nas (clear text).
- Zanni al-Thubut wa Qati al-Dalala (probable transmission but clear meaning): Engineer interviews—they might exaggerate, but the pattern is consistent. Accept as zanni support.
- Maslaha Mursala (unregulated public interest): Is there any maslaha in keeping this debt? The CEO argues: “We shipped faster to capture market.” That’s a maslaha claim. But apply sadd al-dhara’i (blocking the means to harm): The debt now blocks future shipping. The original maslaha is gone.
Also measure the opportunity cost (a form of israf): The team spent 40% of time on workarounds. That is zaman mu’attal (wasted time) which is a form of itlaf al-mal (destruction of wealth). Use qiyas: If a merchant spends money on a broken cart that slows his trade, the hukm is he must repair it to avoid israf. Analogously, you must fix the debt. Evidence is clear: the debt is munkhir (nullifier) of future velocity.
4. SHURA
PRODUCT_LEAD:
Call a cross-functional shura. Invite: 2 engineers (from payment team), 1 QA, 1 product designer, the CEO. Agenda: “We have evidence of debt compounding. What do we do?” Listen first. Engineers say: “We can’t keep shipping like this. It’s demoralizing.” CEO says: “We need to ship the new investment feature next month. Rewriting is a distraction.” The shura reveals a conflict: velocity vs. sustainability. Use Teresa Torres’s “Opportunity Solution Tree” to map: The CEO’s opportunity is capture high‑value investors. The engineer’s opportunity is reduce cognitive load. The shura must find a path that serves both Maqasid. Record dissent: Two engineers want a full rewrite; the CEO wants a quick hack. Document all positions as arā (opinions) to be weighed.
MUJTAHID:
Shura is fard (obligatory) when the matter affects the umma (here, the team). The Mujtahid does not simply count votes; he weighs dalālat al-shar’i (legal indications). The CEO’s opinion has maslaha (market capture) but the engineer’s opinion has darūra (necessity for system survival). Apply the qa’ida (legal maxim): “Al-ḍarar yuzāl” (Harm must be removed). The debt harm is muḥaqqaq (verified). The market opportunity is ẓannī (speculative—competitors may not move). So the shura must tilt toward harm removal. Record the mukhālif (dissenter) and his daleel. The shura concludes: “We need a measured investment—not a full rewrite, but a targeted cleanup of the highest-interest debt.” Document as ittifāq (consensus) with the CEO’s condition: “No more than two sprints, and must enable the investment feature.” This is a fatwa in the making.
End of Part 1. Continue to Part 2 for the Fatwa, Protocol, and Muhasaba.## THE FATWA (HUKM)
HUKM: We will only incur technical debt that is Deliberate and Prudent (as per the Debt Quadrant) and immediately recorded with a repayment plan. Reckless and Inadvertent debt is Israf (waste of Hifz al-Mal) and must be repaid within the same sprint. Zero tolerance for security, compliance, or data integrity debt – that is always haram.
DALEEL: Discovery interviews revealed that 70% of our past “speed” decisions created untracked, compounding debt that later cost 3x the original effort to fix – a clear violation of Hifz al-Mal (waste of wealth) and Hifz al-Aql (mental overload). User evidence showed no feature value from the shortcuts, only bugs. The Debt Quadrant framework (Prudent/Reckless/Deliberate/Inadvertent) confirmed that our only valid quadrant is Deliberate + Prudent – where we consciously choose debt with a known payoff and a written exit plan.
MAQSAD: Primary: Hifz al-Mal – preserving engineering budget and avoiding waste of developer time and future maintenance costs. Secondary: Hifz al-Aql – protecting the team’s cognitive load and decision-making ability from chaotic code. Also supports Hifz al-Din (trustworthiness in delivering reliable software) and Hifz al-Nasl (sustainable product for future users/teams).
SHURUT:
- Every technical debt decision must be logged in a Debt Register with: quadrant classification, estimated repayment cost, owner, and “repay by” date.
- Reckless and Inadvertent debt that enters the codebase (e.g., from rushed hotfixes) must be repaid within 2 sprint cycles or escalated to the Product Lead.
- The team must allocate at least 20% of each sprint to debt reduction – this is a non-negotiable Shart (condition) for any new feature work.
- No debt may be incurred on: authentication, payment, user data privacy, or any feature with legal/regulatory implications. Those are Qati (certain) obligations.
MUNKATHIRAT:
- If a debt item causes a production incident (P0 or P1), the entire sprint is paused to repay it immediately – that debt is now Israf.
- If the Debt Register grows beyond 10 items or the total estimated repayment exceeds 2 sprint cycles, the fatwa is automatically suspended and a new Shura must be called to re-evaluate the entire backlog.
- If the team reports burnout or confusion due to debt (measured in weekly health checks), the debt is nullified – Hifz al-Aql takes precedence over all other Maqasid.
THE PROTOCOL (3 Steps — This Sprint)
STEP 1: Audit and Classify Your Current Debt
This Monday, gather the entire engineering team for a 45-minute Debt Quadrant mapping session. List every known shortcut, hack, or workaround. Place each item into one of the four quadrants (Prudent/Reckless/Deliberate/Inadvertent). Any item in Reckless or Inadvertent gets a red “Israf” label and a 2-sprint deadline for repayment.
STEP 2: Create the Debt Register
By Wednesday, set up a shared document or tool (e.g., a spreadsheet or a GitHub project board). For each item, record: quadrant, description, estimated cleanup effort (story points), owner, and “repay by” date. Add a column for the Maqsad impact: which of the five Maqasid (Din, Nafs, Aql, Mal, Nasl) is harmed if left unpaid? This makes the cost tangible.
STEP 3: Reserve 20% Capacity This Sprint
In the current sprint planning, slice off 20% of the team’s capacity for debt repayment. Do not negotiate this. Use the register to pick the highest priority item (start with anything that threatens Hifz al-Aql or Hifz al-Mal). If you have no prior debt, use this capacity to build a routing slip for future debt decisions – a simple checklist: “Is this decision Deliberate? Is it Prudent? Have we logged it?”
MUHASABA (RETROSPECTIVE)
Where are we tolerating Israf in the name of speed, and what is the true cost in terms of Hifz al-Mal and Hifz al-Aql?
Ask this question at your next retrospective. Sit in silence for 60 seconds before anyone speaks. Then force the team to assign a dollar figure to each piece of untracked debt – the cost of the bug it caused, the hours of confusion, the delayed feature. This isn’t guilt; it’s a calibration. If you cannot name the cost, you are still in Israf. The moment you name it, you are one step closer to Hifz al-Mal.