نود أن نطلق على المملكة المتحدة اسم الشركة الرائدة عالميًا في مجال الذكاء الاصطناعي والتكنولوجيا المالية والابتكار الرقمي. لكن الحقيقة هي: أننا نجهد المهندسين الذين نحتاجهم لتحقيق هذا الطموح.
فبدلاً من تمكين مواهبنا التقنية من الابتكار، تعمل العديد من المؤسسات على إرهاقها بأعمال مكافحة الحرائق والترقيع.
ويقول 66% من المطورين في المملكة المتحدة إنهم يقضون الآن وقتًا أطول في صيانة التعليمات البرمجية مقارنة ببناء أي شيء جديد. ويقول 81% آخرون إنهم ببساطة مرهقون للغاية بحيث لا يمكنهم توفير مساحة للعمل الإبداعي أو المبتكر.
يستمر المقال أدناه
قائد الهندسة الفنية في أوروبا والشرق الأوسط وأفريقيا في Chainguard.
ما نطلبه من المهندسين الآن هو ما يعادل مطالبة سائقي الفورمولا 1 ببناء سياراتهم الخاصة في منتصف السباق، ومن ثم إلقاء اللوم عليهم عندما يخسرون.
لست بحاجة إلى أن تكون مهندسًا لفهم الآثار المترتبة على ذلك.
حان الوقت للحديث عن ضريبة الإنتاجية على المهندسين
سواء اعترفنا بذلك أم لا، فقد قمنا بتطبيع ثقافة العمل حيث يظل المطورون عالقين باستمرار في وضع رد الفعل: محاربة الأعمال المتراكمة، أو فرز نقاط الضعف، أو محاولة كشف كود السباغيتي القديم. هذه هي المشاكل التي لم يخلقوها، ومع ذلك فهي مسؤولة بطريقة أو بأخرى عن حلها.
ليس من المستغرب أن يتزايد إرهاق المطورين. يقول أكثر من ثلث المهندسين (35%) أن الإرهاق هو العائق الأكبر أمام الحصول على تجربة عمل إيجابية، في حين يشعر ثلثا قادة الهندسة الآن بالقلق بشأن الاحتفاظ بالمواهب في ظل هذه الظروف.
والأسوأ من ذلك أن كل هذا الكدح يأتي على حساب الابتكار. الآن، يقضي المهندسون 16% فقط من وقتهم في بناء ميزات جديدة، على الرغم من أن 93% يقولون إنه الجزء الأكثر تحفيزًا في دورهم.
في كل مرة يسقط فيها برنامج CVE جديد، أو يعلن بائع آخر عن استغلال للأمن السيبراني في يوم الصفر، فإن المطورين هم الذين يبتعدون عن العمل الهادف للمنتج لتصحيح المشكلات. هذا ليس الإحباط المتخصصة. إنه فشل واسع النطاق للعملية.
إذا أردنا إنشاء تطبيقات أعمال آمنة بشكل افتراضي، فنحن بحاجة إلى تحويل العبء بعيدًا عن المهندسين الأفراد وتضمين الأمان في وقت مبكر من دورة حياة التطوير. وهذا يعني تقليل عمليات الترقيع التفاعلية وأدوات أكثر أمانًا حسب التصميم.
المهندسون لا يريدون أداة أخرى. يريدون عودة الزمن.
التوازن بين المخاطر والابتكار
يدعم المصدر المفتوح الآن 90% من جميع البرامج، وبينما سمح للمؤسسات بالتحرك والابتكار بسرعة، فقد أدخل أيضًا مخاطر في سلسلة توريد البرامج: كود من مشرفين غير معروفين، وثنائيات لم يتم التحقق منها، ولا مصدر.
تعتبر مدونة ممارسات أمن البرمجيات الجديدة في المملكة المتحدة خطوة أولى مرحب بها – فهي تدعو إلى تطوير برمجيات آمنة وحوكمة مفتوحة المصدر. لكنها لم تعالج بعد المشكلة الجذرية: فنحن ندعم الابتكار برموز برمجية غير موثوقة، والمطورون هم من تُركوا في مواجهة الحرائق.
إذا كانت المملكة المتحدة ترغب في الريادة في مجال الذكاء الاصطناعي، فيتعين عليها التوقف عن التعامل مع أمن سلسلة توريد البرمجيات باعتبارها وظيفة إدارة التصحيح. اجعل الأمان هو الاهتمام الأول للمطورين.
ابدأ بالحد الأدنى من الصور الأساسية الموثوقة ووحدات SBOM الموقعة والمكونات المعززة من السطر الأول من التعليمات البرمجية – وليس كفكرة لاحقة في وقت النشر.
امنح المطورين إمكانية الوصول الافتراضي إلى الحزم الموقعة والصور الأساسية الخالية من الثغرات والمكتبات التي تم التحقق منها كجزء من سلسلة أدواتهم اليومية.
تقوم مؤسسات مثل Snowflake بالفعل بتضمين صور معززة وافتراضيات آمنة وأدوات إنشاء تلقائية في سير عمل المطورين لديها.
لا يمكن للمملكة المتحدة أن تفوز بسباق التكنولوجيا دون بناةها. هل تريد المنافسة في عصر الذكاء الاصطناعي؟ ابدأ بإعطاء مهندسيك المساحة للهندسة.
تحقق من قائمتنا لأفضل المنصات بدون كود.
التعليقات