تلاش برای این که یک کد عالی، تمیز و بی نقص بزنیم اشتباه هست چون همه چیز در این دنیا با تکامل رشد کرده و کسی که خلاف این نظریه مهم در طبیعت پیش بره باید هزینههای زیادی پرداخت کنه که در بیشتر موارد بصرفه نیست! هزینه‌هایی مثل شکست‌ها و هزینههای مالی سنگین، رنج و فرسایش روانی، درگیری با بحران‌‌‌های منابع انسانی و ...!
تکامل یعنی شروع از موجودیتی پایه با قابلیت‌ها و ساختاری ساده و مقدماتی و تاکید بر کلیات و Functionalityهای الزامی با هدف دستیابی به نسخه پایه قابل قبول و قابل حیات و سپس تلاش‌‌هایی دوره‌ای برای اصلاح نقص‌ها و افزایش قابلیت‌ها تا کسب نسخه‌ای پیشرفته.
احتمال میدم که بخشی از شما در نهایت به روش خودتون عمل کنید اما حداقل بیاید به این ایده به دور از پیش فرض‌های ذهنی‌ای که دارید عمیق فکر کنید! به این فکر کنید که چه چیزهایی در اطرافتون بر اساس تکامل به نسخه امروزی خودشون رسیدن و چه چیزهایی بر اساس طراحی و توسعه حرفه‌ای، بی‌نقص و استاندارد در اولین نسخه؟
به خودروها، ساختمان‌ها، گوشی‌های موبایل، ساختارهای مثل شبکه‌های اب و فاضلاب، نیروگاه‌های برق و ... فکر کنید، به چگونگی شکل گیری و پیشرفت علوم مختلف مثل علم فیزیک، شیمی و حتی همین برنامه‌نویسی فکر کنید، به موجودیت‌های خلق شده مستقل از انسان مثل شکل گیری یک دریاچه طبیعی، گونه‌های جانوری، رانش زمین در یک منطقه و ... فکر کنید. فکر کنید و ببیند در چند مورد می‌تونید تکامل رو ببینید و در چند مورد نسخه معکوس اون یعنی شروعی کمالگرایانه.
ایده معکوس تکامل از این جهت قابل نقد هست که بر پایه یک اختلال روانی به نام "کمالگرایی" طراحی شده و می‌گه سعی کن از ابتدا و اولین قدم‌ها عالی و منطبق بر اصول، قوانین و استانداردهای حرفه‌ای سطح بالا پیش بری و حرفه‌ای ادامه بدی! البته چون بحث کمالگرایی خیلی مورد نقد هست افراد معتقد به ایده معکوس همیشه سعی بر توجیه کردن دارن تا خودشون رو از این اتهام نجات بدن ولی مهم نیست که چی می‌گن چون وقتی به رفتارهاشون دقت کنید چیزی که در نهایت مشاهده میشه همون الگو‌هایی هست که اختلال کمالگرایی با اون شناخته میشه.
چنین الگویی یا نهایتا به توقف و شکست ما منجر میشه یا به دلیل محدودیت‌های زمانی، مالی و ... در اخر کار مجبور به عجله و کاهش کیفیت حتی کمتر از کیفیت پیشنهادی الگوی تکامل میشیم! به عبارتی ابتدا با هدف خلق اثری با کیفیت شروع می‌کنیم ولی در اخر هدف میشه این که فقط بزنیم تا تموم بشه و از شر فشارهای روانی و مالی راحت بشیم ولی این انتهای ماجرا نیست بلکه شروع فشارهای روانی، درگیری‌های درون تیمی، مقصر تراشی، متهم‌کردن و متنفر شدن‌ها و .... هست!
متاسفانه در بیشتر موارد افرادی که باعث و بانی اجرای الگوی کمالگرایانه هستن از زیر بار مسئولیت‌ها شانه خالی می‌کنن و حتی بعد از این شکست هم از اون درس نمی‌گیرن!
چند سال پیش وارد یک شرکت شدم تا در پروژه بازنویسی پلتفرم اون مشارکت کنم! یک اتفاق عجب در جریان بود! اون‌ها وقت بسیار زیادی برای طراحی ریزترین جزئیات می‌گذاشتن و تاکید بسیار فراوان بر پیش رفتن طبق عالی‌ترین و سطح بالاترین استاندارهای در توسعه بود و مدام هم مدیر فنی‌ای که این تیم رو رهبری می‌کرد بر اولویت داشتن کیفیت بر هر چیزی تاکید می‌کرد!
یکی از استاندارهای طراحی و توسعه نرم افزار که خیلی هم بر اون تاکید میشه این هست که قبل از توسعه بهتر است تا طراحی به صورت mouckup، prototype، flowchart و ... صورت بگیره و هر چقدر روی این طراحی وقت گذاشته بشه و ایراداتش گرفته بشه پروسه توسعه هم راحت‌تر و هم با کیفیت‌تر میشه. اجرای چنین استانداردی علاقه‌ی خیلی از توسعه دهنده‌های نرم افزار هست. به همین جهت من هم از این اتفاق استقبال کردم ولی وقتی پیش رفتیم شرایط متفاوت شد. من به دلیل علاقه‌ام به بحث‌های روانشناسی و اقتصاد نکاتی رو در اون شرکت متوجه شدم و دیدم این استراتژی با این که ایده‌الی دوست داشتنی هست ولی با واقعیت‌های کشور ایران و شرایط اون شرکت همخوانی نداره! من متعجب شدم که چرا تیم مدیریت و تیم مالی شرکت با چنین الگویی موافقت کردن ولی بعد متوجه شدم CTO فشارهایی اورده و فعلا تونسته به نوعی قانع یا ساکتشون کنه!
بودم فهمیدم اخر و عاقبت این ایده خوب نیست و این ریسک‌ها قابل چشم پوشی نیستن هر چند که که در ظاهر جذاب و ایده‌ال به نظرم میرسن! برای همین نکات و توضیحاتم رو به اون CTO گفتم.
پیشنهاد من این بود که همین طرحی که الان موجود هست جزئیات خوبی داره و تا الان هم وقت زیاد برای پروسه طراحی صرف شده به نظرم بهتر هست وارد عمل بشیم و شروع به توسعه بکنیم حالا بعدا اگر در جزئیات تغییراتی لازم شد در همون کد اعمال می‌کنیم و در پروسه توسعه هم لازم نیست اینقدر در رعایت استانداردها سخت‌گیر باشیم، مثلا در بحث git استانداردهایی که گفته شده بود خیلی دقیق و سطح بالا ولی به درد یک پروژه بسیار بزرگ که توسط چند تیم و ده‌ها نفر توسعه پیدا میکنه می‌خورد نه این پروژه که متوسط رو به کوچک به حساب میاد و کلا ۴ نفر نیروی فنی داره و هر کس روی بخش مجزای خودش هست! دلیلم هم این هست که بودجه این شرکت چند صد میلیاردی نیست که یک تیم برای پروژه فعلی بگیره و یک تیم هم برای توسعه این پروژه طبق این استاندارها پس با این که فعلا تیم مدیریت قبول کردن ما تمرکزمون رو روی پروژه جدید بذاریم ولی چون درامد شرکت از پروژه قبل هست قطعا مجبور میشم اون رو هم فیکس باگ و توسعه بدیم و ساختار اون پروژه با این یک زمین تا اسمون هست و به لحاظ روانی این می تونه اثار مخربی داشته باشه و نیروها رو به دلیل این مدام سوییچ کردن کند و خسته کنه. جدا از این چون تعداد نفرات کم هست اگر بخواهیم همه این استانداردها رو رعایت کنیم قطعا کند پیش خواهیم رفت و یک بخش که در حالت عادی توسعه‌ش شاید یک روز طول بکشه در طی این فرایند استاندارد زمانش به ۳ روز افزایش پیدا میکنه و این یعنی ما امروز هم تحت فشار مالی و مدیریتی شرکت قرار نگیریم و با کیفیت پیش بریم قطعا در اینده این فشار چنان مثل موج بر سر ما خراب خواهد شد که اخراش شب هم باید تو شرکت بخوابیم تا این پروژه تکیمل بشه و قطعا در اون روزها حتی نمیشه استعفا داد و فرار کرد و مجبور به تحمل اون شرایط سخت به دلیل تصمیم غلط امروز میشیم! من سعی کردم توضیح بدم و قانعشون کنم که این پلن استاندارد و ایده‌ال شما بد نیست ولی به این زمان و این مکان نمی‌خوره و عاقبت خوبی نخواهد داشت. بله اگر شرکت اینقدر بزرگ بود و بودجه زیادی داشت که چند تیم مجزا بگیره یکی روی پروژه قدیم یکی روی پروژه جدید کار کنه و اینقدر هم زمان داشت که واسش مهم نباشه کی اماده میشه چون نسخه‌ای که بالا هست هم کیفیت آنچنان بدی نداره و توسط تیم مربوطه‌ش هم داره توسعه پیدا میکنه من مشتاق بودم که در تیم پروژه جدید باشم ولی واقعیت این هست که شرایط این شرکت با این توصیف زمین تا اسمون فرق داره پس باید واقعیت رو در نظر بگیریم و مسیرمون رو اصلاح کنیم.
من گفتم ولی بعد مطرح کردنش با برخورد تند اون CTO مواجه شدم و به این نتیجه رسیدم که تلاش در چنین فضایی عاقلانه نیست و ازشون جدا شدم و در متن استعفام هم به این نکات اشاره کردم ولی پاسخ مناسبی دریافت نکردم چون اون‌ها ترجیح دادن به CTO خودشون اعتماد کنن!
بعد از چند سال بی‌خبری چند روز پیش یادشون افتادم و گفتم برم ببینم اخر این ماجرا چی شد و دیدم که متاسفانه بعد از گذشت حدود ۴ سال هنوز همون پروژه قدیمی بالا هست و خبری از اون نسخه ایده‌ال و استاندارد که قرار بود جایگزین بشه نیست و این که دقیقا چه اتفاقاتی رخ داده تا کجا پیش رفتن و بعد متوقف شدن و کلا چه هزینههای مالی و روانی‌ای به اون تیم و شرکت تحمیل شده نمی‌دونم ولی میشه یه حدس‌هایی زد!
این که عنوان رو "لطفا کثیف کد بزنید" انتخاب کردم نباید شما رو به این اشتباه بندازه تکامل یعنی تنبلی و زیر کار در رفتن! این که ما متخصص‌های تنبلی باشیم و وقت کافی برای تمرین و افزایش توانایی‌های خودمون نذاریم و به تکنولوژی‌ها و ساختارهای استاندارد جدید و بروز مجهز نشیم و یا از اون طرف دیگه شرکت‌ها تلاش نکنن تا افراد متخصص رو بکار بگیرن و به افراد و راهکارهای خیلی ضعیف راضی بشن چیزی نیست که در الگوی تکامل به اون تاکید میشه!
ما باید برای حرفه‌ای بودن خودمون و اشنایی و ارتقا سطح توانایی تخصصی خودمون تلاش کنیم (البته نه تلاشی کمالگرایانه) و از اون طرف هم شرکت‌ها همواره باید تلاش کنن تا افرادی متخصص و البته متناسب با سطح تخصصی پروژه و بودجه در دسترس جذب کنن (جذب منطقی و نه کمالگرایانه) اما وقتی این تیم تشکیل شد باید واقعیت‌های موجود رو در نظر بگیره و بسته محدودیت زمان و بودجه پروژه سطح پیشرفتگی و چگونگی طراحی و توسعه محصول رو تعیین کنه.
مدیر فنی متخصص کسی نیست که استانداردترین روش‌ها رو به کار بگیره تا بی‌نقص‌ترین محصولات رو خلق کنه بلکه کسی هست که بتونه بین واقعیت‌های زمانی و مالی پروژه و شرایط جانبی شرکت و استاندارهای موجود یک تعادل منطقی برقرار کنه تا هدف اصلی که خلق نسخه پایه قابل قبول هست در بصرفه‌ترین زمان و با بصرفه‌ترین هزینه محقق بشه و بتونه این رو به سایر تیم‌ها مثل مدیریت هم توضیح بده و اون‌ها رو قانع کنه.
تعریف نسخه پایه قابل قبول در بحث تکامل خیلی مهم هست! یک نسخه پایه قابل قبول درست هست که لازم نیست بی‌نقص و طبق استاندارهای سطح بالا توسعه پیدا کنه ولی باید بتونه حداقل‌های لازم برای بقا، ادامه دادن و حذف نشدن رو داشته باشه و به تعادل که اون هم یکی از قوانین و واقعیت‌های طبیعت این جهان هست پایبند باشه.
در واقع تمام نکاتی که در بالا توضیح داده شده یک وسط و میانه داره که افراط در اون‌ها ما رو از این طرف بوم و تفریط هم از اون طرف دیگر بوم پایین میندازه. افراط میشه همون کمالگرای و معیارهای سخت‌گیرانه (بالاتر از نیازهای تکامل پیش رفتن) و تفریط میشه تنبلی کردن و زیر کار در رفتن (پایین‌تر از نیاز تکامل عمل کردن) و تکامل میشه به اندازه و منطبق بر واقعیت‌ها محیطی، اقتصادی، زمانی و ... انرژی گذاشتن و پیش رفتن.
بسیاری از برنامه‌نویس‌ها تلاشی افراطی دارن تا پروژه خودشون رو با بهترین ساختارها و طبق اصولی‌ترین استانداردهای توسعه نرم افزار پیش ببرن و اغلب هم این تفکر به دلایلی از جمله پیشنهادهای افراد و مقالات مشهور، داستان‌سرایی‌هایی که در مورد برخی شرکت‌های مطرح میشه، اختلالات فردی مثل (داشتن اختلال کمالگرایی، طرحواره نقص و شرم، طرحواره معیارهای سخت‌گیرانه) در فرد ایجاد و پیگیری میشه و اینطور القا میشه که حرفه‌ای کسی است که بسیار بر کیفیت تاکید کنه و کدی با بهترین پرفورمنس و خوانایی و .... ارائه بده در حالی که این تعریف از واقعیت دور و به اختلال منفی کمالگرایی نزدیک هست که نتیجه اون هم در اکثر موارد شکست و توقف پروژه و یا فشار بر افراد سریع‌تر به نتیجه رساندن پروژه هست که باعث میشه کیفیت حتی به زیر کیفیت پیشنهادی الگوی تکامل بره و پروژه‌ای که در ابتدا هدفش کیفیت عالی بود خودش به کلکسیونی از ایرادات جدی تبدیل بشه!
پیشنهاد میشه تا افراد بجای تاکید بر کیفیت بر واقعیت‌های این جهان مثل تکامل و تعادل تاکید کنن و سعی کنن از یک نسخه پایه قابل قبول شروع کنن و به صورت دوره‌ای اون رو اصلاح کنن و به اون قابلیت‌های بیشتری اضافه کنن تا نهایتا به نتیجه مطلوب برسن. نسخه پایه قابل قبول هم نسخه‌ای هست که حداقل‌های لازم برای بقا و تکامل رو داشته باشه و باید مراقب بود که سادگی در نسخه اولیه که مورد تاکید الگوی تکامل هست رو با تنبلی و زیر کار در رفتن اشتباه نگیریم و پایین‌تر از حداقل‌های لازم پیش نریم.
