فخ الكمالية
قضيت سنتين من حياتي المهنية في انتظار اللحظة المثالية للشحن.
ليس حرفياً في الانتظار — كنت أبني. بلا توقف. لكن في كل مرة اقتربت من شحن شيء ما، كنت أجد عيباً: معالجة الأخطاء لم تكن أنيقة بما يكفي، مخطط قاعدة البيانات يمكن أن يكون أكثر تطبيعاً، استجابة API يمكن أن تكون أكثر RESTful. لذا كنت أعيد الصياغة. مرة أخرى. ومرة أخرى.
وفي الوقت نفسه، شحن شخص آخر نسخة فوضوية وحصل على تعليقات المستخدم. شكلت تلك التعليقات منتجهم بطرق مهمة. ظل منتجي مثالياً وغير مرئي بشكل مثالي.
إليك ما تكلفه الكمالية بالفعل:
الأول: تأخير الملاحظات. لا يمكنك معرفة ما إذا كانت قرارات تصميمك صحيحة حتى يستخدمها أشخاص حقيقيون. كلما تلقيت الملاحظات في وقت مبكر، كان من الأرخص إصلاحها. الانتظار 6 أشهر للشحن يعني 6 أشهر من البناء في الظلام.
الثاني: عدم وجود ميزة تنافسية. إذا كان هناك بناء آخر يعمل على نفس المشكلة، وشحنوا أولاً، فإنهم يملكون قاعدة المستخدمين. تصل نسختك المثالية إلى غرفة فارغة.
الثالث: عدم الرؤية. نظام مشحون مع حواف خشنة هو أفضل بلا حدود من نظام غير مشحون مع عمارة مثالية. واحد يخدم الناس. واحد يخدم الأنا الخاصة بك.
الرابع: ضريبة إعادة الكتابة. ستعيد كتابة هذا الكود. ليس لأن عمارتك سيئة، بل لأنك تعلمت أكثر منذ كتابتها. يتم إعادة كتابة كل نظام مُشحون في النهاية. من الأفضل دفع تلك الضريبة ضد نظام يعمل بالفعل.
شحن v1. ملك v2.
التحول العقلي الذي غيّر كل شيء بالنسبة لي جاء من إعادة صياغة بسيطة:
لا يجب أن أبني النظام المثالي. يجب أن أشحن النظام الصحيح الآن، وأملك تحسينه لاحقاً.
هذا يغيّر كل شيء.
مع تلك الإذن، يمكنني:
- إطلاق مع مصادقة أساسية بدلاً من بناء تكامل OAuth محكم
- استخدام استعلام SQL بسيط بدلاً من قضاء يوم في التحسين مع Redis
- النشر مع شهادة موقعة ذاتياً بدلاً من انتظار إعداد HTTPS المناسب
- الشحن برسائل خطأ أساسية بدلاً من إطار عمل شامل لمعالجة الأخطاء
لا شيء من هذه مثالي. كل هذه جيدة بما يكفي. و "جيدة بما يكفي للشحن" هي أفضل بلا حدود من "مثالية لكن لم تشحن".
الأنظمة التي أملكها — حيث شحنت مبكراً وكررت بجد — هي تلك التي تهم حقاً. ليس لأنها بدأت مثالية، بل لأنها كانت حقيقية، خدمت الناس، واهتممت بما يكفي لإصلاحها.
الكمالية امتياز
إليك شيء لاحظته: الكمالية غالباً ما تكون امتيازاً.
إذا كان لديك وقت غير محدود وميزانية غير محدودة، يمكنك مطاردة الكمال. لكن معظمنا لا نملك. لدينا مواعيد نهائية. لدينا مستخدمون ينتظرون. لدينا فواتير للدفع.
هذا ليس قيداً — إنه وضوح. القيود تجبرك على تحديد الأولويات. على فصل الضروري عن الاختياري. على الشحن.
مهندس مبتدئ بموعد نهائي ضيق يشحن كوداً أفضل من مهندس كبير بوقت غير محدود. ليس لأن المبتدئ أكثر مهارة، بل لأن الموعد النهائي يفرض القرارات.
أفضل العمل لمؤسس يشحن بسرعة ويكرر بدلاً من فريق يناقش العمارة لأشهر. ستتفوق النسخة الأولى الفوضوية من المؤسس على مسودة الفريق المثالية.
عقلية الملكية
هناك شيء آخر يتغير عندما تشحن مبكراً: أنت تملك النتائج.
عندما تشحن، فأنت لا تقتصر على كونك بناءً تنفذ تصميماً. أنت مسؤول عما يعمل في الإنتاج. أشخاص حقيقيون يعتمدون عليه. إذا انقطع، تصلحه. إذا كان بطيئاً، تحسنه. إذا كره المستخدمون، تسمع عنه.
هذا الملكية غير مريحة. إنه أيضاً تحويلي.
لأن فجأة، كل تلك القرارات "المعمارية المثالية" لا تهم كثيراً مثل الواقع العملي. نظام معماري مثالي لا يستخدمه أحد هو فشل. نظام معماري فوضوي يخدم المستخدمين بشكل جيد هو انتصار.
بمجرد أن تملك نظاماً في الإنتاج، لا يمكنك العودة إلى نقاء معماري كمقياس نجاح. تقيس النجاح: هل يعمل؟ هل يستخدمه الناس؟ هل يمكنني الحفاظ عليه؟
ما أشحنه الآن
هذه الأيام، إليك إطار العمل الخاص بي:
هل يمكنني شحن هذا في أسبوع واحد مع تغطية 80٪؟ نعم؟ شحنه.
هل هناك مسار حرج لجعله يستحق الشحن الآن؟ نعم؟ شحنه.
هل سيسمح الشحن المبكر لي بتعلم شيء يغيّر الطريقة التي أبني بها النسخة التالية؟ دائماً تقريباً نعم؟ شحنه.
الكمال هو عدو الشحن. والأنظمة المشحونة، مع كل حواف قاسية والديون التقنية، هي ما يهم بالفعل.
فجر ليست معماري مثالياً. إنترستيلار لها قرارات غريبة كنت سأتخذها بشكل مختلف الآن. الأنظمة التي شحنتها ليست قطع متحفية — إنها منتجات حية وتنفس وتتغير.
وأنا فخور بجميعها.
هذا هو التحول: من الكمالي إلى المالك. من المعماري إلى البناء. من الانتظار للحظة المثالية إلى الشحن وملك الواقع غير المثالي.
شحن v1. ملك v2. بناء v3.