🧠چرا تقابل کاذب (سندروم "VS") گفتمان در اکوسیستم های توسعه رو مسموم می‌کنه؟

🚨خیلی خلاصه اگر بخوایم با انتزاع پایین و در سطح خود #علم صحبت کنم، می خوایم یادآوری کنیم که یادمون به انواع مغالطه‌های پنهان در گفتمان‌های فنی و خطاهای شناختی مون باشه. به راحتی نذاریم ذهن‌مون آلوده بشه چون ممکنه راه نجات آسانی از این آلودگی ها برامون مهیا نشه.

🔬اخیراً در جاهای مختلف دست نوشته هایی را دیدم که اصلا انتظار این مدل نگارش‌ها را نداشتم و نگارنده ها دنبال مقایسه سیب و پرتقال هستند، شاید در ذات بگید میشه مقایسه کرد، منم میگم باشه میشه ولی هدف چی هست؟ مثلا جایی تیتر زدن که آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟ (تقابل DDD با تیم های کوچک) یا رحیم فیروزی عزیز در کانالش نوشته "سادگی یا اسکیلبیلیتی؟" و جایی نوشته شد بیاین در مورد "FP vs OOP" صحبت کنیم. اما چرا همیشه این سندروم "VS" اینقدر جذاب مطرح میشه در صورتی که ترکیبی از مغالطه‌هایی مثل false dichotomy (#دوگانه_کاذب) و confirmation bias، بحث‌ها رو ساده‌انگارانه می‌کنه و راه گفتمان واقعی رو می‌بنده.
⏳در پست DDD مثل همیشه قصد اینه بگن DDD تقریبا همیشه برای توسعه در سازمان های large scale هست! حتی برای اینکه جلوی بعضی ایرادات را از همان ابتدا بگیرند، تعریف های عجیبی از مدل سازمان مورد نظر میدن که بزرگی سازمان یا تعداد کارمند را صرفا قبول ندارند! انتخاب اشتباه موضوع باعث شده همش دنبال توجیح باشند. اینجا قصد نداریم بگیم DDD بدرد چه نوع توسعه ای می خوره چون اعتقاد راسخ دارم که این رویکرد توسعه بدرد هر نوع توسعه نرم افزاری می خوره و اصلا ارتباطی به سایز پروژه یا سازمان نداره. این موضوع را به شکل عمیق در آینده ای نزدیک در جلسات #خوانش کتاب DDD اریک ایوان مطرح خواهیم کرد.
⏳در مقاله رحیم عزیز واقعیت اینه سادگی و اسکیلبیلیتی دو موضوع کاملا مجزا و حتی کاملا بی ربط به هم هستند. هر چند نیاز بود رحیم عزیز مشخص کنه منظورش از "سادگی" دقیقا چی هست؟ چون وقتی در مقابل مقیاس پذیری قرارش میدیم چندین برداشت میشه ازش داشت، مثلا من احساس کردم منظورش اینه در ابتدای توسعه هر مدلی دوست داری برو جلو، بعدا که نیاز شد تغییرش میدی! ولی این تفکر آیا با اصول #علمی در یکسو هست؟ اگر همه مهندسان دنیا اینو بگن چه بلایی سر #پایداری جامعه ها میاد؟ فکر کنید یک تیم توسعه ساختمان بگن فعلا یک طبقه ساختمان بسازیم، اگر استقبال خوب بود بعدا 20 طبقه دیگه روی این ساختمان میسازیم! این نوع نگاه ممکنه نشان از کمبود دانش موثر در توسعه بخصوص #توسعه_پایدار باشه.
⏳در موضوع FP و OOP هم همین‌طوره مثلا FP از اصول OOP مثل encapsulation عملا استفاده می کنه و اونا تکمیل‌کننده‌ن همدیگن نه چیزی در تقابل!

💬 اوضاع وقتی بدتر میشه که گوینده یا نگارنده در مقام توجیح بازم بخواد موضوعات بی ربط دیگر را به مسیر گفتمان بیاره، مثلا با آوردن صفت هایی مثل over-engineering (پیچیدگی بی‌جا) یا micro-optimization (بهینه‌سازی‌های جزئی بی‌فایده) فاجعه‌ای تمام عیار رقم می خوره. کسی دانش و بینش ضعیفی داره به طور مثال نمی تونه تفاوت complicated و complex (همان‌طور که در تئوری سیستم‌ها می‌گن، پیچیدگی ذاتی نیست، بلکه از تعاملات می‌آد) را تشخیص بده و حتی ظرافت #سوال_باز بودن این حوزه ها را درک کنه و اصولا با مفهوم خود کلمه #سیستم آشنایی کافی را ندارد و حرف از سیستم (محصول) پیچیده میزنه. یا جزییات و تفاوت های ساده‌سازی واقعی (simplification) رو از ساده‌انگاری (oversimplification) تشخیص نمیده ولی با ابهام کامل قصد داره مسیر روشنی را به دیگران هدیه بده! 😉
وای به روزی که این شخص تصمیم‌گیر باشد! سازمان (جامعه، شرکت، تیم، ...) رو به مسیر اشتباه می‌بره و هیچ‌کس جرات نمی‌کنه بگه "شاه لخته!" 😅

🔗 بیاید بحث‌هامون رو بر اساس مکمل بودن و واقعیت بسازیم، نه تقابل‌های کاذب و ساختگی.
🌟 نظر شما چیه؟ 🌟
🌟 شما کدوم "VS" بی‌ربط دیگه دیدید؟ کامنت بذارید! 🌟

🔗 در پست بعد موضوع مهم و خیلی مرتبط با این حوزه یعنی #یادگیری_تطبیقی (Adaptive Learning) را کمی بیشتر مطرح می کنیم که یادمون باشه یادگیری، اصول خیلی مهمی داره و نباید دنبال مقایسه های اشتباه باشیم و هر موضوعی و هر فردی نیاز به بررسی و توسعه یکتایی داره.