لا تخترع العجلة من جديد

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

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

المألوف ليس عيبًا #

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

البرامج التي تعمل في العراق منذ سنين على هذه الصورة، لها سبب. الناس يريدونها هكذا، ولا يمكنك أن تغيّر تفكيرهم بين ليلة وضحاها.

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

متى يستحق التعقيد ثمنه؟ #

لا أقول إن البساطة قانون مطلق، بل أقول إنها نقطة البداية، وإن التعقيد ثمن تدفعه حين تضطر إليه فعلًا، لا حين تتوقع أنك ستضطر إليه بعد سنتين.

• هل يحل هذا التعقيد مشكلة قائمة اليوم، أم مشكلة أتخيلها؟

• لو جاء مبرمج جديد غدًا، كم يومًا يحتاج ليفهم ما بنيته؟

• ما أبسط ما يمكن أن يعمل، وما الذي يمنعني من تسليمه اليوم؟

ابدأ بالاعتراف بعمل من سبقك #

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

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