Technical Debt: إمتى تكون مشكلة Business فعلًا، وإمتى تكون إعادة كتابة النظام غلطة؟

في أي Software Company شغالة بقالها فترة، عاجلًا أو آجلًا حد هيقول:

"إحنا محتاجين نعيد كتابة النظام."

أحيانًا يكون عنده حق.

ممكن الـCodebase فعلًا أصبحت Constraint على الـBusiness: Releases خطرة، Incidents بتتكرر، Security Changes صعبة، Infrastructure Cost غير منطقية، أو Subsystem قديمة مانعة الشركة تنفذ حاجة العملاء محتاجينها.

لكن أحيانًا كلمة Technical Debt معناها حاجة أبسط بكثير:

"لو بدأت النهارده، كنت هبنيها بطريقة مختلفة."

الاتنين مش نفس الحاجة.

الشركة مش المفروض تصرف شهور في إعادة بناء Software شغالة لمجرد إن Technology أحدث ظهرت أو Engineers مش عاجبهم Old Code.

السؤال المفيد هو:

الـTechnical Debt دي بتكلف الـBusiness إيه دلوقتي، وهتمنعنا نعمل إيه بعد كده؟

هنا تتحول Technical Debt من Engineering Complaint إلى Investment Decision.

Technical Debt مش معناها Old Code

Code ممكن تكون قديمة جدًا لكنها Stable وValuable ورخيصة في التشغيل.

وفي المقابل Code عمرها ست شهور ممكن تكون مكلفة جدًا في التغيير.

العمر وحده Diagnostic ضعيفة.

الأفضل نفهم Technical Debt كShortcut في Design أوImplementation أوOperations أوOrganization، والنتيجة إن Future Work أصبحت أصعب أو أخطر أو أغلى.

أمثلة:

• Module كل Feature لازم تعدل فيها.
• مفيش Automated Coverage حول Critical Financial Logic.
• Deployment Process شخص واحد فقط فاهمها.
• Business Rules مكررة بشكل مختلف عبر Services.
• Database Structure تخلي Product Change مطلوبة Risky.
• Dependencies لم تعد تحصل على Security Updates.
• Manual Operations بتسبب Incidents متكررة.
• Architecture لا تدعم Scale أوCompliance Requirement جاية.

Business Problem مش إن Code شكلها وحش.

المشكلة هي النتيجة.

ترجم الـDebt إلى Business Consequence

لما Engineering Team تطلب وقت لـTechnical Debt، اطلب منها تكمل الجملة دي:

بسبب الـDebt دي، إحنا حاليًا بنخسر أو بنخاطر بـ ______.

إجابة مفيدة ممكن تكون:

• Normal Release تحتاج يومين Regression إضافيين.
• Billing Incidents تتكرر لأن 3 Systems بتحسب نفس Rule بشكل مختلف.
• مش قادرين نعمل Safe Upgrade لـDependency عليها Security Exposure.
• كل Enterprise Integration تحتاج أسبوعين Engineering زيادة بسبب Coupling معينة.
• Engineer واحدة فقط تقدر Deploy الـPlatform.
• Infrastructure Cost بتكبر أسرع من Usage بسبب Architectural Constraint.
• Initiative موجودة في Roadmap لا يمكن تنفيذها بأمان بالData Model الحالية.

دلوقتي Leadership تقدر تقارن Remediation باستثمارات ثانية.

"Architecture سيئة" صعب تعمل لها Prioritization.

"كل Customer Integration بتكلفنا أسبوعين زيادة بسبب Coupling دي" أسهل بكثير في القرار.

مش كل Technical Debt لازم تتدفع

Debt استعارة اقتصادية لسبب.

في Debt فائدتها قليلة.

تخيل Internal Admin Screen اتبنت بسرعة من 3 سنين. Code مش Elegant، لكنها تتغير مرة في السنة، لا تسبب Incidents ومفيش Security Concern.

إعادة كتابتها ممكن تنتج تقريبًا Zero Business Value.

في المقابل، Module ثانية مش Perfect لكنها في Checkout Path وبتتغير كل أسبوع.

Debt هنا فائدتها أعلى لأن كل Future Change تدفع Penalty.

علشان كده اعمل Prioritization جزئيًا حسب Change Frequency وBusiness Criticality.

Ugly Code في Quiet Corner ممكن تكون أقل أهمية من Moderately Messy Code في قلب الـProduct.

أربع تكاليف بدور عليهم

Technical Debt المفيدة في النقاش غالبًا ترتبط بواحدة على الأقل من أربع Categories.

1. Delivery Cost

هل الـDebt بتخلي Valuable Changes أبطأ أو أغلى؟

دور على Repeated Workarounds، Long Regression Cycles، Unexpected Dependencies، Excessive Reviews، Features تلمس Areas غير مرتبطة، أو Engineers بتتجنب أجزاء من الـCodebase.

2. Reliability وSecurity Risk

هل الـDebt بتزود احتمال أو Impact الـFailure؟

مثل Unsupported Dependencies، Missing Observability، Fragile Deployments، Recurring Production Incidents، Weak Authorization Boundaries أوCritical Logic بدون Reliable Tests.

3. Operating Cost

هل Architecture بتخلق Recurring Expense غير ضرورية؟

ممكن تكون Cloud Infrastructure أوManual Operations أوSupport Load أوVendor Cost أوEngineering Time مبالغ فيها.

4. Strategic Constraint

هل الـDebt مانعة الشركة تعمل حاجة محتاجاها؟

مثل دخول Enterprise Market، Compliance Model، Multi-tenancy، New Channel Integration، فصل Product Line، Scale Workload أوتغيير Pricing/Billing Architecture.

Strategic Constraints ممكن تبرر Work حتى قبل ظهور Incidents واضحة.

Technical Debt ممكن تكون Organizational كمان

مش كل Technical Bottleneck موجودة في Source Code.

تخيل Production System:

• محدش عارف مين Owner لـService.
• Documentation ناقصة.
• شخص واحد فقط يعرف Deployment Procedure.
• Architecture Decisions موجودة فقط في Old Chat Messages.
• مفيش Team تملك Dependency Upgrades.

Rewrite مش هتصلح ده تلقائيًا.

ممكن تعمل New Codebase جميلة جدًا وتكرر حولها نفس Organizational Debt.

Technical Leadership لازم تعالج Ownership وOperating Practices وKnowledge Distribution بجانب Code.

ليه Engineers طبيعي تحب Rewrites؟

Rewrite جذابة لأنها تقدم Clean Mental Model.

Current System فيها سنين من Compromises وEdge Cases وHistorical Decisions.

New System تبدو أبسط لأنها لسه ما قابلتش Reality.

وده يعمل مقارنة خطيرة:

Old Production System بكل Known Complexity

مقابل

New Design قبل ما Production Complexity ترجع لها

الثانية تقريبًا دائمًا هتبدو أنظف على Diagram.

لكن كثير من Strange Rules في Legacy System موجودة لأن Business اكتشفت حاجة Original Designers ما كانوش يعرفوها.

قبل ما تمسحها، افهم هي موجودة ليه.

Rewrite مش بتبدأ من Zero

حتى لو رميت كل Old Code، الـBusiness لسه عندها Existing Users وData وIntegrations وPermissions وBilling Rules وOperational Procedures وHistorical Edge Cases وReporting Expectations وSupport Workflows وContracts.

Rewrite لازم تعيد اكتشاف أوMigration لكل ده.

علشان كده تقدير Rewrite بمقارنة حجم Source Code مضلل.

إنت بتنقل Running Business System، مش بتعيد إنتاج Repository.

التكلفة المخفية: نظامين في نفس الوقت

أثناء Rewrite، Old Product غالبًا مش هتقدر توقف التغيير فيها.

Customers لسه محتاجين Fixes، Sales لسه بتبيع، Security Issues لسه تظهر.

الشركة تضطر تقرر: New Feature تتعمل في Old System؟ تستنى New System؟ تتبني مرتين؟ نFreeze جزء من Business؟

وده يعمل Dual-system Cost.

كل ما Rewrite تطول، التكلفة دي ممكن تكبر.

إمتى Argument الـRewrite تكون ضعيفة؟

خليك حذر لما السبب الأساسي يكون:

• Framework مش Trendy دلوقتي.
• Language جديدة أسرع نظريًا.
• Team تفضل Architecture Style ثانية.
• Code مش Clean زي ما كنا هنعملها النهارده.
• Microservices شكلها More Scalable.
• Competitor يستخدم Stack أحدث.

ولا سبب من دول غلط تلقائيًا، لكن محتاج Demonstrated Constraint أوOpportunity وراءه.

Technology Preference وحدها سبب ضعيف لتعريض Working Business Functionality لـMigration Risk.

إمتى Rewrite تصبح أكثر منطقية؟

Rewrite تستحق Serious Consideration لما Incremental Change لا يمكن بشكل معقول إزالة Material Constraint بتكلفة وRisk مقبولين.

مثل Core Platform Boundary غير متوافقة جذريًا مع Required Product Model، Technology لا يمكن صيانتها بأمان ولا يوجد Practical Migration Path، Existing Data/Tenancy Architecture تمنع Strategic Requirement، أوReliability Failures ناتجة من Design لا يمكن عزلها تدريجيًا بتكلفة مقبولة.

حتى هنا، "Rewrite Everything" مجرد Migration Strategy من عدة Strategies.

Refactor ولا Replace ولا Rewrite؟

القرار غالبًا يتقدم كاختيارين: Keep Legacy أوRewrite Everything.

لكن فيه Options أكثر.

Refactor in Place

حسن Existing Code مع استمرار Shipping. مناسب لما Boundaries يمكن تحسينها Incrementally والBehavior الأساسية صحيحة.

Isolate

حط Stable Interface حول Problematic Subsystem بحيث أجزاء أقل تعتمد عليها Directly.

Replace One Capability

انقل Domain واحدة مثل Search أوBilling أوNotifications أوReporting خلف New Implementation.

Strangler Migration

انقل Capabilities تدريجيًا بعيدًا عن Old System مع استمرار Product في التشغيل.

Full Rewrite

أعد بناء Complete System واعمل Migration للUsers/Data/Workflows. أحيانًا ضرورية، لكنها أكبر Migration Surface ولازم يكون وراءها Business Case متناسب.

صلح Boundary قبل Implementation

غلطة شائعة إنك تعيد كتابة Bad Module بدون ما تغير السبب اللي خلاها Bad.

لو 10 أجزاء في Product تعدل Billing Tables مباشرة، ممكن تعيد كتابة Billing بشكل جميل لكن تسمح لنفس 10 أجزاء تعدل New Tables.

Coupling هترجع.

Improvement أقوى ممكن تبدأ بإنشاء Clear Billing Boundary وتحريك Callers وراءها.

Architecture Debt كثيرًا ما تعيش في Relationships بين Components، مش داخل Code فقط.

قِس Hotspots بدل Opinions

بدل ما تسأل Developers عن أسوأ Code، ادمج خبرتهم مع Evidence.

دور على Areas فيها Combination من High Change Frequency، High Defect Frequency، High Incident Impact، Long Review/Test Cycles، Dependencies كثيرة، High Cognitive Load وSignificant Business Importance.

Module Engineers مش بتحبها لكن نادرًا تتلمس قد لا تكون Highest-value Target.

Module كل الناس بتغيرها ومحدش واثق فيها غالبًا تستحق الاهتمام.

اعمل Technical-Debt Register يفهمها CEO

Debt Item مفيدة ممكن تكون:

Problem: Checkout Rules موجودة في 3 Implementations.

Evidence: Production Defects مشابهة تكررت وكل Pricing Change تحتاج Coordinated Edits.

Business Impact: Release Risk وEngineering Effort أعلى في Revenue-critical Changes.

Proposed Action: نقل Pricing Rules خلف Owned Interface واحدة ثم Migration للCallers تدريجيًا.

Expected Result: Source of Truth واحدة للPricing Behavior وSmaller Change Surface.

Risk of Waiting: Duplicate Behavior أكثر مع إضافة Pricing Features جديدة.

لاحظ إن مفيش "Code Quality: 4/10".

Score بدون Consequences نادرًا تساعد Executive ياخد قرار.

رتب الـDebt حسب Exposure مش الإحراج

ممكن تستخدم Qualitative Model بسيطة:

Impact × Frequency × Change Demand × Risk Exposure

وبعدين تراعي Remediation Cost وReversibility.

مش محتاج Fake Mathematical Precision.

الهدف تفرق بين High-impact Debt في Critical Path، Risky Debt محتاجة Containment قريب، Opportunistic Debt تصلحها لما Work تعدي جنبها، وCosmetic Debt ممكن تفضل.

Mature Engineering Organization مرتاحة مع قرار عدم إصلاح بعض الـDebt.

Technical Debt وProduct Deadlines

Conflict شائعة:

Business: محتاجين Feature الشهر ده.

Engineering: محتاجين 3 شهور نصلح Architecture الأول.

بدل "Features vs Quality"، اسأل:

• إيه Minimum Remediation المطلوبة علشان نشحن Feature بأمان؟
• إيه Debt هتسوء لو ما عملناش حاجة؟
• نقدر Isolate New Capability؟
• إيه Risk اللي بنقبلها بتأجيل Remediation؟
• إمتى هنراجع Accepted Debt دي؟

كده Trade-offs تبقى Explicit بدل Conflict دائم.

أحيانًا أسرع حل إنك توقف إضافة Debt جديدة

حتى لو مفيش Budget لـMajor Modernization، تقدر تغير Trajectory:

1. Define Ownership.
2. امنع New Direct Dependencies.
3. أضف Tests حول Critical Behavior.
4. أضف Observability في أماكن Failures صعبة التشخيص.
5. اعمل Interface حول Problematic Area.
6. اعمل Migration تدريجي لما Product Work تلمسها.

System ممكن تصبح أسهل بشكل واضح بدون Rewrite Program.

استخدم Incidents كArchitecture Evidence

بدل ما تسأل "مين غلط؟" فقط، اسأل:

ليه Class الـMistake دي تقدر توصل Production بشكل متكرر؟

يمكن Critical Behavior بلاAutomated Protection، Deployment Fragile، Ownership غير واضحة، Shared Component Blast Radius كبيرة، أوSystem تسمح Invalid State.

Incident Learning تكشف Technical Debt معها Business Evidence مباشرة.

Security Debt لها Threshold مختلفة

مش كل Debt لازم تستنى Incident واضحة.

Unsupported Software وWeak Access Boundaries وExposed Secrets وMissing Security Updates وDangerous Privilege Models ممكن تخلق Risk قبل أي Failure تاريخية.

في Security-sensitive Debt، قيّم Credible Exposure وPotential Impact بدل انتظار Frequency.

Infrastructure Cost ممكن تكشف Architecture Debt

Cloud Cost أحيانًا Pricing Problem، وأحيانًا Architecture Problem.

Workload قد تعيد Process نفس Data أوتشغل Oversized Resources باستمرار أوتScale Application كلها بسبب Component واحدة Heavy.

قبل Rewrite، حدد Actual Cost Driver.

Targeted Architecture Change ممكن تحقق معظم Benefit بـMigration Risk أقل كثيرًا.

اختبار الـRewrite

قبل Approve Full Rewrite، عايز إجابات واضحة على:

1. أنهي Measurable Business Constraint تعملها Current System؟
2. ليه Constraint دي لا يمكن إزالتها Incrementally بتكلفة وRisk مقبولين؟
3. أنهي Behavior وData وIntegrations لازم تفضل محفوظة؟
4. Old وNew Systems هيتعايشوا إزاي أثناء Migration؟
5. Data Migration هنعمل لها Verification إزاي؟
6. إيه Rollback أوContainment Strategy؟
7. Ongoing Product Development هتكمل إزاي؟
8. أنهي Milestone تثبت إن New Architecture فعلًا بتزيل Constraint؟

لو Plan مش قادرة تجاوب، غالبًا عندك Technology Aspiration، مش Migration Strategy لسه.

Modernization Sequence أفضل

في Systems كثيرة، Sequence أكثر أمانًا:

Observe → Measure → Stabilize → Define Boundaries → Isolate Hotspots → Replace Incrementally → Remove Old Paths

ده يخلي الشركة تتعلم قبل ما تراهن Platform كلها على Architectural Bet واحدة، ويطلع Value أثناء Migration مش فقط في النهاية.

إزاي أتعامل مع Codebase Audit؟

Codebase Audit مفيدة مش المفروض تنتهي بقائمة طويلة بكل حاجة Engineer ممكن تحسنها.

لازم تجاوب:

• إيه اللي بيخلق Business أوOperational Risk دلوقتي؟
• إيه اللي بيبطّأ Important Roadmap Work؟
• أنهي Areas آمنة نسيبها؟
• أنهي Problems محتاجة Containment؟
• إيه اللي يبرر Refactoring أوReplacement؟
• أنهي Architecture Decisions صعب الرجوع عنها؟
• أنهي Sequence تعمل أعلى Reduction في Risk أوDelivery Cost؟

Output لازم تكون مرتبة حسب Consequences، مش Personal Coding Preferences.

الهدف مش Clean Codebase

مفيش Production Codebase تفضل Clean للأبد.

Business تتغير، Requirements تتغير، Teams تتغير، Technology تتغير.

الهدف System الشركة تقدر تغيرها بأمان كفاية، بسرعة كفاية، وبتكلفة منطقية بالنسبة للمكان اللي Business رايحاه.

أحيانًا ده يحتاج Serious Modernization.

أحيانًا يحتاج Rewrite.

وأحيانًا أكثر Technical Decision مسؤولية هو إنك تسيب Ugly but Stable Subsystem في حالها.

الـTechnical Debt بتبطّأ Roadmap عندك — ولا Team بتقترح Rewrite بدون Business Case واضحة؟

أقدر أراجع Architecture وDelivery Hotspots وReliability Risks وModernization Options، وبعدها نفصل Debt اللي فعلًا بتكلف Business عن Debt اللي ممكن تستنى بأمان.

ناقش AI & Codebase Audit أوEngineering Architecture Review مع فادى مندي.

الهدف مش نعيد كتابة Software أكثر. الهدف نصرف Engineering Effort في الأماكن اللي تغير Economics أوRisk الـBusiness.

---

مرتبط: AI & Codebase Audits، Engineering Architecture، Engineering Leadership، Fractional CTO، Custom Software Development، ومقال ليه مشروع البرمجيات بيتأخر رغم إن فريق التطوير شغال طول الوقت؟