چرا مهندسان نرم‌افزار نمی‌توانند درباره زبان‌های برنامه‌نویسی منطقی تصمیم بگیرند
انتخاب یک زبان برنامه نویسی، شاید گران‌ترین تصمیمی باشد که هر شرکت نرم‌افزاری می‌گیرد؛ اما ما معمولاً با آن مثل یک بحث فنی ساده رفتار می‌کنیم.
بعد از دو دهه مشاهده شکست‌ها و فروپاشی‌های شرکت‌هایی که به خاطر همین تصمیم اشتباه ورشکست شدند، به یک حقیقت ناخوشایند رسیده‌ام: این تصمیم‌ها معمولاً فنی نیستند، بلکه احساسی، هویتی و گاهی مبتنی بر غرور هستند و همین تصمیم‌های ظاهراً فنی، در سکوت، سرعت توسعه و بودجه شرکت‌ها را از بین می‌برند.
تجربه‌ای که مسیر حرفه‌ای مرا عوض کرد
اوایل دوران کاری‌ام در استارتاپی به نام Takkle کار می‌کردم؛ شبکه اجتماعی نوظهوری که آینده درخشانی داشت.
با رفتن ناگهانی مدیر فنی، منِ جوان بیست‌وچند ساله از مهندس ارشد به سمت معاون مهندسی (VP of Engineering) ارتقا پیدا کردم و تیمی ۱۲ نفره را رهبری می‌کردم. عملکرد ما خوب بود، اما هیئت‌مدیره نگران کم‌تجربگی من بود و تصمیم گرفت یک مدیر فنی ارشد (CTO) با تجربه استخدام کند.
مدیر جدید از جامعه‌ی Perl آمده بود؛ با چند جلد از کتاب‌های معروف O’Reilly روی میزش.
اولین تصمیمش این بود: «PHP انتخاب اشتباهی است؛ باید همه‌چیز را با Perl بازنویسی کنیم.»
تحلیل او از تفاوت‌های دو زبان، در ظاهر منطقی به نظر می‌رسید، اما در واقع یک تحلیل نمایشی بود، تصمیم از قبل گرفته شده بود.
نتیجه فاجعه‌بار بود. سرعت تیم سقوط کرد، باید از صفر زبان جدید را یاد می‌گرفتیم، پروژه ۹ ماه عقب افتاد و هزینه ماهانه از ۲۰۰ هزار دلار به ۵۰۰ هزار دلار رسید.
در نهایت، سیستم جدید زیبا و فنی بود، اما وقتی آماده شد، فرصت بازار از دست رفته بود؛ فیس‌بوک از دانشگاه‌ها فراتر رفته بود و ما پولی برای ادامه نداشتیم.
سال‌ها بعد هنوز از خودم می‌پرسیدم: اگر با همان PHP ادامه می‌دادیم چه می‌شد؟
سیستم ما کار می‌کرد، پیشرفت داشتیم، هزینه کمتر بود و جالب اینکه فیس‌بوک هم با PHP موفق شد.
اما سؤال بزرگ‌تر این بود: چطور ممکن است یک رهبر باتجربه چنین اشتباه پرهزینه‌ای کند؟
وعده‌ها و واقعیت‌ها
وعده‌ها:
- مهاجرت به Perl باعث می‌شود معماری بهتری بسازیم.
- بازنویسی کامل، کیفیت کد و جذب نیرو را بهبود می‌دهد.
واقعیت:
- سرعت تیم فروپاشید.
- هزینه‌ها دو برابر شد.
- و در نهایت، شرکت شکست خورد.
الگوی تکراری در گوگل، MongoDB و فراتر از آن
در سال‌های بعد، در نقش‌های مختلفی از جمله مدیر محصولات زبان‌ها در گوگل و مدیر تیم‌های چندزبانه در MongoDB، بارها همین الگو را دیدم. مهندسان باهوش، با داده‌هایی واقعی اما ناقص، بر سر زبان‌ها بحث می‌کردند، هر کدام «درست» می‌گفتند، اما هیچ‌کدام تصویر کامل را نمی‌دیدند.
حتی در Google Cloud، مشتریان بزرگ با همین مشکل دست‌وپنجه نرم می‌کردند.
دو دهه بعد، همان صحنه را تکرار شده دیدم: معاون مهندسی شرکتی در حال ارائه گزارشی بود تا رهبری را قانع کند که باید سیستم بعدی را با Rust بنویسند.
استدلال‌هایش عیناً شبیه همان تحلیل‌های Perl در Takkle بود و جالب اینکه، تمام ویژگی‌هایی که به‌عنوان مزیت Rust مطرح می‌کرد، در واقع در Go قوی‌تر بودند!
وقتی از او پرسیدم چطور زبان‌های دیگر را مقایسه کرده‌اند، پاسخش تکان‌دهنده بود: «راستش… بررسی خاصی نکردیم. همه دارن درباره Rust حرف می‌زنن.» و این یعنی تصمیمی ۵۰ میلیون دلاری بر اساس هیجان و هویت، نه تحلیل واقعی.
دو گفت‌وگو در هر بحث فنی وجود دارد
در هر گفت‌وگوی فنی درباره زبان‌ها، دو مکالمه هم‌زمان در جریان است:
- مکالمه‌ی آشکار:
«Rust حافظه را ایمن‌تر مدیریت می‌کند.»
«Go سریع‌تر کامپایل می‌شود.»
«Python اکوسیستم یادگیری ماشین غنی‌تری دارد.» - مکالمه‌ی پنهان:
«من یک برنامه‌نویس Rust هستم.»
«می‌خواهم کسی باشم که با Rust کار می‌کند.»
«نمی‌توانم خودم را کسی بدانم که Rust را انتخاب نمی‌کند.»
در Takkle، مدیر فنی ما داشت مکالمه پنهان را انجام می‌داد. تحلیلش از Perl درست بود، اما هدفش دفاع از «هویت» خودش بود، نه انتخاب درست برای شرکت. شرکت ما ماهی ۳۰۰ هزار دلار بیشتر خرج نکرد تا سیستم بهتری بسازد، بلکه هزینه کرد تا او بتواند «CTOِ Perl» باشد، نه «CTOِ PHP».
مغز ما برای دیدن این تعصب ساخته نشده است
پژوهش‌های عصب‌شناسی نشان می‌دهند که وقتی باورهای مربوط به «هویت» ما به چالش کشیده می‌شوند، مغز دقیقاً مانند زمان تهدید فیزیکی واکنش نشان می‌دهد. بخش آمیگدالا (مرکز ترس) و قشر اینسولا (مرکز احساس انزجار و درد عاطفی) فعال می‌شوند. سیستم پیش‌فرض مغز که حس «من کیستم» را حفظ می‌کند، وارد حالت دفاعی می‌شود.
«برای درک دیدگاهی متفاوت، باید نسخه‌ای متفاوت از خودت را تصور کنی.» نتیجه ساده است: به همین دلیل، وقتی مهندسی که خود را «Pythonista» می‌داند به Go نگاه می‌کند، مغزش ناخودآگاه اطلاعات را تهدید تلقی می‌کند. ما دروغ نمی‌گوییم؛ فقط واقعا باور داریم که منطق‌مان درست است در حالی که مغزمان در حال دفاع از هویت‌مان است، نه ارزیابی واقعیت.
صنعت ما بر پایه‌ی گفت‌وگوی اشتباه ساخته شده است
ما خودمان را Rustacean ،Gopher یا Pythonista می‌نامیم. این فقط نام نیست، هویت است و صنعت نرم‌افزار بر همین هویت بنا شده: رقابت‌های فنی، بنچمارک‌ها، فریم‌ورک‌های مقایسه‌ای… اما حقیقت این است که گفت‌وگوی پنهان، قوی‌تر از گفت‌وگوی فنی است.
هر بار که از یک توسعه‌دهنده Rust می‌خواهید زبان‌ها را ارزیابی کند، در واقع از قبل Rust را انتخاب کرده‌اید، فقط ۲ میلیون دلار خرج می‌کنید تا این تصمیم از پیش‌گرفته‌شده «منطقی» به نظر برسد.
هزینه واقعی تعصب زبانی
پژوهش‌ها نشان می‌دهد انتخاب فناوری می‌تواند بین ۴۰ تا ۶۰ درصد از کل هزینه توسعه در چرخه عمر محصول را تعیین کند. گزارش Stripe نیز می‌گوید توسعه‌دهندگان ۴۲ درصد از زمان خود را صرف بدهی فنی می‌کنند.
وقتی تصمیم‌هایتان را بر اساس هویت می‌گیرید، در واقع سرعت، بودجه و آینده شرکت را گروی حفظ غرور فردی می‌گذارید.
راه‌حل: بازتعریف انتخاب زبان به عنوان تصمیم اقتصادی
اگر مکالمه‌ی پنهان را نمی‌توان حذف کرد، باید موضوع گفت‌وگو را تغییر داد. به جای اینکه بپرسیم: «کدام زبان بهتر است؟» بپرسیم: «هزینه‌ی واقعی این زبان برای ما چیست؟» نه فقط از نظر حقوق و سرعت توسعه، بلکه در بدهی فنی، پیچیدگی عملیاتی، جذب نیرو و دوام اقتصادی.
انتخاب زبان برنامه‌نویسی، یک تصمیم اقتصادی است، نه فنی. زبانی که انتخاب می‌کنید، فرهنگ تیم، مسیر رشد، بودجه و حتی احتمال بقای شرکت شما را تعیین می‌کند. ما به چارچوبی نیاز داریم که هزینه‌های پنهان را آشکار کند، چارچوبی که تصمیم‌گیری را از سطح احساس به سطح عدد و اقتصاد منتقل کند.
