لماذا يستغرق البرنامج الجيد وقتًا ولا يمكن استعجاله

استغرق Flask ثماني سنوات حتى وصل إلى الإصدار 1.0. وما زال SQLite في تطوير نشط منذ عام 2000 ويحصل على تحسينات ملموسة. عمر نواة Linux يتجاوز ثلاثة عقود، وربما تزداد جودةً مع مرور الوقت. في المقابل، يُتوقع من أغلب الشركات الناشئة المدعومة برأس مال مخاطر أن تُظهر نموًا خلال 18 شهرًا، أو أن تشرح لماذا لم تفعل.

هناك فجوة متنامية بين المدة الحقيقية التي يحتاجها بناء البرمجيات الجيدة، والمدة التي نتوقعها. الضغط لإطلاق المنتجات بسرعة ليس خاطئًا بحد ذاته، لكنه يخلق ثقافة يُنظر فيها إلى الصبر على أنه نقص في الطموح، وتُوصف فيها المشاريع الصامدة بأنها «بطيئة» في السنوات التي تصحح فيها مسارها بهدوء.

أسطورة النجاح بين ليلة وضحاها

تقريبًا كل «نجاح مفاجئ» في عالم البرمجيات له قصة طويلة وراءه. استُخدم React داخليًا في فيسبوك لأكثر من عام قبل أن يُفتح مصدره. وقضت Rust سبع سنوات في التطوير قبل الوصول إلى 1.0. بدأ PostgreSQL مشروعًا بحثيًا عام 1986، ولم يصبح الخيار الأول للإنتاج إلا في عقد 2010، أي ما يقارب 30 عامًا من التحسين الهادئ والمستمر.

ما يبدو ظهورًا مفاجئًا هو غالبًا نتيجة تحسينات متراكمة تعبر عتبة الظهور. كان البرنامج يتحسن طوال الوقت، لكن الناس لم ينتبهوا إلا عندما أصبح جيدًا بما يكفي ليصعب تجاهله.

كتب Armin Ronacher، مبتكر Flask، عن هذا بشكل مباشر. بدأ Flask مزحةً في كذبة أبريل عام 2010، ثم تحول إلى مشروع جاد تقريبًا بالصدفة. سنوات من العمل التدريجي، من إصلاح الحالات الحدية وتحسين التوثيق وإعادة التفكير في الـ APIs، حوّلته إلى واحد من أشهر أطر عمل الويب في Python. لم تضع أي من تلك السنوات سدى، فكل واحدة منها قوّت الأساس.

لماذا تحتاج البرمجيات إلى مكوّن زمني لا يمكن تقليصه

هناك مشكلات لا يمكن حلها بشكل أسرع بإضافة المزيد من الأشخاص أو ببذل جهد أكبر. لاحظ Fred Brooks ذلك عام 1975 في كتابه The Mythical Man-Month، والفكرة الأساسية لم تتغير: بعض جوانب تطوير البرمجيات متسلسلة بطبيعتها، ولا يمكن تنفيذها بالتوازي.

• فهم مجال المشكلة. لا يمكنك استيعاب مساحة مشكلة بالكامل قبل أن تعيش فيها لفترة. يعكس الإصدار الأول لأي برنامج افتراضاتك الأولية، ويعكس الإصدار الثاني ما تعلمته من الأول. الفهم الحقيقي يحتاج إلى تكرارات، والتكرارات تحتاج إلى وقت.
• تصميم الـ API وثباته. الواجهات البرمجية الجيدة تنشأ من الاستخدام. لا يمكنك تصميم API مثالي في فراغ، بل تحتاج إلى مستخدمين حقيقيين يصطدمون بحالات حدية حقيقية. المكتبات التي تستعجل الوصول إلى 1.0 غالبًا ما تندم على قراراتها التصميمية المبكرة لسنوات.
• الحالات الحدية والتقوية. أول 80% من الميزة تستغرق 20% من الوقت، أما الحالات الحدية المتبقية ومعالجة الأخطاء وخصوصيات المنصات فتستهلك الـ 80% الأخرى. هذه النسبة ليست كسلًا، بل هي طبيعة جعل البرمجيات موثوقة.
• المجتمع والنظام البيئي. لا تصبح الأداة مفيدة حقًا إلا عندما تملك توثيقًا ودروسًا تعليمية وإضافات ومجتمعًا يجيب عن الأسئلة. هذا النظام البيئي لا يمكن تصنيعه، بل ينمو عضويًا مع الوقت.

ضرر الاستعجال المصطنع

شعار «تحرّك بسرعة واكسر الأشياء» كان مقبولًا لشبكة اجتماعية تبحث عن ملاءمة المنتج للسوق. أما بالنسبة للبنية التحتية وأدوات المطورين وقواعد البيانات وكل ما تعتمد عليه أنظمة الآخرين، فهو فلسفة سيئة للغاية. عندما تستعجل بناء البرمجيات الأساسية، تتراكم الأعطال وتتضاعف.

شاهدتُ عدة مشاريع واعدة في المفتوح المصدر تنهار لأنها حاولت النمو أسرع مما تسمح به أسسها. النمط متوقع: يصبح المشروع شائعًا، فيشعر المشرفون بضغط لإطلاق الميزات بسرعة، تنخفض الجودة، يحترق المساهمون، ويهاجر المستخدمون إلى بديل أكثر استقرارًا. المفارقة أن التمهل كان سيوصلهم إلى أبعد.

المشاريع التي تصمد ليست تلك التي أُطلقت بأسرع وتيرة، بل تلك التي اتخذت قرارات جيدة في وقت مبكر بما يكفي حتى لا تضطر إلى إعادة كتابة كل شيء لاحقًا.

الدين التقني ليس مجرد شيفرة فوضوية. إنه القرارات التي تُتخذ تحت ضغط الوقت وتُقيّد الإمكانيات المستقبلية. كل اختصار تأخذه لتطلق أسرع هو ضريبة تُدفع على كل تغيير لاحق. بعض الاختصارات تستحق العناء، لكن يجب أن تتخذها عن وعي، لا لأن أحدًا قرر بشكل تعسفي أن الموعد النهائي هو يوم الثلاثاء القادم.

كيف يبدو الصبر عمليًا

الصبر في تطوير البرمجيات لا يعني التحرك ببطء من أجل البطء. يعني أن تكون متعمدًا فيما تبنيه، وصادقًا بشأن المدة التي تستغرقها الأمور. هناك عدة أنماط رأيتها تنجح جيدًا:

• أطلق مبكرًا، لكن التزم ببطء. أصدر برنامجك للمستخدمين سريعًا لتحصل على ردود الفعل، لكن كن متحفظًا جدًا فيما تلتزم به كـ API مستقر. استخدم ترقيم 0.x بسخاء، ووضّح أن الأشياء قد تتغير.
• قل لا للميزات. كل ميزة تضيفها هي ميزة ستصونها للأبد. أفضل المشاريع واضحة بشأن نطاقها. يسرد SQLite صراحةً الأشياء التي لن يفعلها أبدًا، وهذا الانضباط هو سبب كونه قاعدة البيانات الأكثر انتشارًا في العالم.
• استثمر في الأساسيات. التوثيق والاختبارات ورسائل الأخطاء والأداء ليست جذابة، لكنها تتراكم. مشروع موثق جيدًا ومزود بمجموعة اختبارات متينة يمكن أن يتقدم في السنة الثالثة أسرع مما يتقدم مشروع ضعيف التوثيق في السنة الأولى.
• احمِ طاقة المشرفين. الإرهاق هو القاتل الأول لمشاريع المفتوح المصدر. الوتيرة المستدامة أهم من سرعة السباقات القصيرة. مشرف يعمل 20 ساعة مركزة في الأسبوع لخمس سنوات ينجز أكثر ممن يعمل 80 ساعة في الأسبوع لستة أشهر ثم يختفي.

فخ السرعة في الشركات الناشئة

تواجه الشركات الناشئة توترًا مشروعًا: عليها أن تتحرك بسرعة لتبقى، لكن التحرك بسرعة مفرطة يخلق أنظمة هشة تتحول إلى عبء مع التوسع. الشركات التي تنجح في هذا عادةً تفرّق بين نوعين من السرعة.

سرعة التكرار — مدى سرعتك في اختبار الأفكار والحصول على ملاحظات المستخدمين وتغيير الاتجاه. يجب تعظيمها. دورات قصيرة، ونماذج أولية سريعة، واستعداد للتخلي عن الأشياء.

سرعة الالتزام — مدى سرعتك في تثبيت القرارات المعمارية والـ APIs العامة ونماذج البيانات. يجب تقليلها. حافظ على قابلية التراجع عن الأشياء قدر الإمكان. كلما أجّلت القرارات غير القابلة للتراجع، زادت المعلومات المتاحة لك عندما تتخذها أخيرًا.

الخطأ الذي تقع فيه معظم الشركات الناشئة هو الخلط بين النوعين. تلتزم بالبنى المعمارية بالسرعة نفسها التي تكرر بها الميزات، ثم تقضي السنتين التاليتين في دفع ثمن قرارات متسرعة.

ما نتعلمه من المشاريع التي صمدت

البرمجيات التي نعتمد عليها أكثر من غيرها تشترك في سمة واحدة: لقد وُصفت جميعها بأنها «بطيئة» في وقت ما. كان PostgreSQL الخيار المملّ بينما كان MySQL الخيار السريع والفوضوي. وكان يُقال إن Python «بطيئة جدًا» بينما كان Perl الخيار العملي. واستغرق Git سنوات حتى أصبح قابلًا للاستخدام من قبل البشر العاديين.

ما امتلكته هذه المشاريع هو الوقت: الوقت لارتكاب الأخطاء والتعلم منها وبناء شيء متين. لم تحاول أن تكون كل شيء لكل الناس في السنة الأولى، بل حاولت أن تتقن غرضها الأساسي، وكانت مستعدة لترك هذا الإتقان يأخذ الوقت الذي يحتاجه.

في المرة القادمة التي تشعر فيها بالإحباط لأن مشروعًا «يستغرق وقتًا طويلًا»، فكّر في أن الأشياء التي تعتمد عليها أكثر، مثل نظام التشغيل وقاعدة البيانات وبيئة تشغيل اللغة ونظام التحكم بالإصدارات، استغرقت كلها وقتًا أطول مما توقعه أي أحد. وهذا بالتحديد هو سبب نجاحها.

بعض الأشياء تحتاج وقتًا فحسب. أفضل رد ليس مقاومة هذه الحقيقة، بل بناء أنظمة وفرق وتوقعات تأخذها في الحسبان.