Hermes Bot
93 lines
11 KiB
Markdown
93 lines
11 KiB
Markdown
**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:
|
||
1. **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).
|
||
2. **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.
|
||
3. **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. |