فکر می‌کنید اگر کدهای برنامه شما دو برابر شود، پیچیدگی برنامه هم دو برابر می‌شود. ولی واقعیت این است که هر زمان که شما بر حجم کد می‌افزایید، برنامه شما به صورت نمایی پیچیده‌تر می‌شود. هر اضافه کردن کوچک، هر تغییر، هر وابستگی و هر اختیار، اثری مضاعف دارد. اگر همین طور بی‌پروا به کد اضافه کنید، قبل از این که متوجه شوید، یک غول بی شاخ و دم خواهید ساخت.
روش مقابله با این پیچیدگی، نوشتن نرم‌افزار کمتر است. نرم‌افزار کمتر یعنی ویژگی‌های کمتر، کد کمتر و اتلاف نیروی کمتر.
نکته مهم تبدیل یک مسأله پیچیده -که به نرم‌افزار زیادی نیاز دارد- به مسأله‌ای ساده است که به نرم‌افزار کمتری نیاز دارد. شما ممکن است که عین مسأله اصلی را حل نکنید و این صحیح است. ولی حل کردن 80 درصد مسأله با 20 درصد سعی و تلاش، یک موفقیت بزرگ است. معمولاً مسأله بزرگ، آن قدرها هم بزرگ نیست که برای حل به پنج برابر تلاش بیشتر نیاز داشته باشد.
نرم‌افزار کمتر یعنی رها کردن گوی شیشه‌ای پیش‌بینی. به جای تلاش برای پیش‌بینی مشکلات آینده، فقط با مشکلات حال حاضر سروکار دارید. چرا؟ چون ترس‌هایی که از آینده دارید اغلب هرگز به بار نمی‌نشینند. خودتان را در باتلاق حل چنین مسأله‌های تخیلی نیاندازید.
از ابتدا ما نرم‌افزارهایمان را حول مفهوم نرم‌افزار کمتر طراحی کرده‌ایم. هر جا که امکان داشته، مسأله سخت را به مسائلی ساده‌تر تقسیم کرده‌ایم. فهمیده‌ایم که راه‌حل‌های مسأله ساده، نه فقط برای پیاده‌سازی و پشتیبانی آسان‌ترند، بلکه برای فهمیدن و استفاده کردن هم آسان‌ترند. تمام تفاوت ما با رقبایمان همین است. به جای تلاش برای ساختن محصولی که کارهای بیشتری انجام دهد، محصولاتی می‌سازیم که کار کمتری انجام دهد.
این که کدام ویژگی‌ها را اضافه یا حذف کنید، ارتباط زیادی با نرم‌افزار کمتر دارد. هرگز از «نه» گفتن به درخواست ویژگی‌هایی که انجام آنها سخت است نترسید. تا وقتی که مطمئن نشدید آن ویژگی‌ها ضروری هستند، با حذف آنها زمان و تلاش خود را حفظ کنید و بر آشفتگی‌ها نیافزایید.
همچنین آهسته‌تر حرکت کنید. روی یک ایده یک هفته هیچ کاری نکنید تا ببینید بعد از فروخوابیدن هیاهوی اولیه، آیا همچنان ایده ای فوق العاده است؟ مدت زمانی که ایده ها را در آب نمک می خوابانید، غالباً به ذهن شما کمک می کند تا یک راه حل ساده تر بیابد.
شما می‌شنوید: «روش پیشنهادی شما 12 ساعت طول می‌کشد ولی من می‌توانم آن را در یک ساعت انجام دهم. روش من «الف» را انجام نمی‌دهد ولی «ب» را انجام می‌دهد». بگذارید نرم‌افزار راه خودش را پیدا کند. بگذارید برنامه‌نویسان برای راهی که فکر می‌کنند بهتر است مبارزه کنند.
همچنین به جای نوشتن برنامه بیشتر به دنبال مسیرهای انحرافی باشید. آیا می‌توانید ظاهر کار را عوض کنید و راهی را به مشتریان پیشنهاد دهید که نیازی به برنامه‌نویسی بیشتر نداشته باشد؟ برای مثال آیا می‌توانید به جای دستکاری عکس‌ها در کارگزار، به مشتریان پیشنهاد کنید که عکس‌های کمتر از پنجاه کیلو بایت بارگذاری کنند؟
برای هر ویژگی‌ای که به نرم‌افزار تحمیل می‌شود، از خودتان بپرسید آیا راهی وجود دارد که بدون این که کد زیادی نوشته شود، آن را به برنامه اضافه کرد؟ فقط آن قدر کد بنویسید که به آن نیاز دارید، نه بیشتر. به دنبال این کار، برنامه کوچک‌تر و سالم‌تر می‌شود.
هیچ «کد»ی از «بی کد»ی، منعطف‌تر نیست
راز طراحی نرم‌افزار خوب در دانستن آن چیزهایی نیست که باید به کد اضافه شوند، دانستن چیزهایی است که نباید وارد شوند. تشخیص نقاط سخت و ساده کار و این که چه جاهایی را باید خالی گذاشت، به جای این که سعی شود همه چیز در طراحی چپانده شود.
Brad Appleton، مهندس نرم‌افزار، نقل از (There is No Code more flexible than NO Code!)
پیچیدگی ارتباط خطی با اندازه ندارد
مهم‌ترین قانونی مهندسی نرم‌افزار که در عین حال ناشناخته‌ترین آنها هم است: پیچیدگی ارتباط خطی با اندازه ندارد ... پیچیدگی یک برنامه 2000 خطی بیشتر از دو برابر برنامه‌ای با اندازه نصف است.
The Ganssle Group به نقل از Keep it Small
یک برنامه‌نویس شاد، برنامه‌نویسی پربازده است. به همین دلیل ما برای شادی بهینه‌سازی می‌کنیم و شما هم باید همین کار را بکنید. هرگز فقط بر مبنای استانداردهای صنعتی و معیارهای کارایی، ابزارها و شیوه‌ها را انتخاب نکنید. موارد غیر عینی را ببینید: آیا اشتیاق، افتخار و هنرمندی وجود دارد؟ آیا واقعاً از هشت ساعت کار در چنین محیطی راضی و شاد هستید؟
این مسأله به ویژه برای انتخاب زبان برنامه‌نویسی مهم است. بر خلاف دیدگاه عموم، آنها در یک سطح ساخته نشده‌اند. با وجود این که هر زبان برنامه‌نویسی تقریباً می‌تواند هر برنامه‌ای را ایجاد کند، ولی زبان مناسب نه تنها این تلاش را ممکن و تحمل پذیر می‌نماید بلکه آن را خوشایند و توان‌افزا می‌کند. این‌ها همه برای خوشایند کردن جزئیات کوچک کار روزانه است. شادی تأثیری پلکانی دارد. برنامه‌نویس شاد کار درست انجام می‌دهد. آنها کدی ساده و قابل خواندن می‌نویسند. روش‌های تمیز، با معنی، قابل خواندن و برازنده را انتخاب می‌کنند. آنها خود را سرگرم می‌کنند. ما برنامه‌نویسی به زبان Ruby را یک سعادت می‌دانیم و با چارچوب خودمان (Rails) آن را به دیگران هم منتقل می‌کنیم. هر دوی آنها یک هدف و مأموریت را دنبال می‌کنند و آن بهینه‌سازی برای انسان‌ها و شادی آنها است. به شما هم توصیه می‌کنیم یکبار این ترکیب را بیازمایید.
به طور خلاصه گروه شما باید با ابزاری که دوست دارد کار کند. ما اینجا درباره زبان برنامه‌نویسی گفتیم ولی این مفهوم برای برنامه‌ها، محیط‌های برنامه‌نویسی و هر چیز دیگری نیز صادق است.ترکیبی را انتخاب کنید که افراد را به هیجان بیاورد. در نتیجه شما هیجان و انگیزه ایجاد نموده و محصول بهتری تولید می‌کنید.
انواع مهندسانی که به آنها نیاز دارید
اولین دلیلی که ما ترجیح دادیم برنامه خودمان را با استفاده از Ruby on Rails بسازیم برازندگی، سودمندی و طراحی زیبای آن بود. Ruby on Rails تلاش می‌کند تا مهندسانی را که به مسائلی از این قبیل اهمیت می‌دهند به خود جذب کند.... این‌ها دقیقاً همان مهندسانی هستند که شما در گروه خود به آنها نیاز دارید زیرا آنها برنامه‌های برازنده، سودمند و زیبایی برای برنده شدن در بازار تولید می‌کنند.
Charles Jolley، مدیر Nisus Software (نقل از Signal vs. Noise)
به کد گوش کنید. کد پیشنهادهایی را ارائه می‌کند. بعضی چیزها را رد می‌کند. به شما می‌گوید دام‌ها و تله‌ها کجا است. راه‌های جدید برای انجام کارها را پیشنهاد می‌کند. به شما کمک می‌کند که از مدل‌های کم نرم‌افزار استفاده کنید.
آیا یک ویژگی جدید به هفته‌ها زمان و هزاران خط کد نیاز دارد؟ کد به شما می‌گوید که احتمالاً راه بهتری وجود دارد. آیا به جای شیوه‌‌ای پیچیده که ده ساعت زمان برای برنامه‌نویسی چیزی لازم دارد، راهی ساده برای انجام آن در یک ساعت وجود دارد؟ باز هم کد شما را راهنمایی می‌کند. به حرف‌هایش گوش کنید.
کد می‌تواند شما را به اصلاحاتی راهنمایی کند که ارزان و سبک هستند. وقتی راهی ساده آشکار می‌شود به آن اهمیت بدهید. مطمئن باشد ویژگی‌ای که ساخت آن آسان است ممکن است صد در صد همن چیزی که در ذهن شما است نباشد ولی چه اشکالی دارد؟ اگر به خوبی کار می‌کند و به شما امکان می‌دهد که روی چیزهای دیگر کار کنید، محافظ و نگهبان شما است.
گوش کنید
نگران طراحی نباشید، اگر به کد خوب گوش کنید طراحیِ خوب نمایان خواهد شد ... به افراد فنی گوش کنید. اگر آنها از سختی ایجاد تغییرات شکوه می‌کنند، آن شکوه‌ها را جدی گرفته و به آن افراد زمان بدهید تا بتوانند مشکلات را رفع کنند.
Martin Fowler، محقق ارشد، ThoughtWorks (نقل از Is Design Dead?)
چه می‌شد اگر برنامه‌نویسان برای حذف کد دستمزد می‌گرفتند ...
اگر برنامه‌نویسان به جای نوشتن کد جدید از حذف کدهای نرم‌افزار دستمزد می‌گرفتند، نرم‌افزار در کل بسیار بهتر می‌شد.
Nicholas Negroponte، استاد فناوری رسانه‌ها در MIT (نقل از And, the rest of the (AIGA Conference) story)
ما معمولاً بدهی را فقط از جنبه مالی می‌شناسیم ولی بدهی انواع دیگری نیز دارد. خیلی راحت می‌توانید بدهی کد و طراحی نیز داشته باشید.
اگر از کدهای بد ولی در عین حال کاربردی و شلوغ استفاده می‌کنید، بدهی خود را افزایش می‌دهید. اگر از طراحی‌ای به اندازه کافی خوب ولی نه صد درصد خوب استفاده می‌کنید، باز هم خطای خود را تکرار می‌کنید.
انجام دادن این کار در طول زمان خوب است. در حقیقت، اغلب اوقات تکنیکی ضروری است که کمک می‌کند تا هر چه سریع‌تر واقعی شوید. ولی باید بدانید که این بدهی است و باید جایی آن را با تمیز کردن کد شلوغ و طراحی مجدد صفحه‌های نه خوب و نه بد تسویه کنید.
همانطور که مرتب مقداری از درآمد خود را برای پرداخت مالیات در نظر می‌گیرید، باید مرتباً مقداری از وقت خود را برای تسویه حساب بدهی‌های کد و طراحی کنار بگذارید. اگر این کار را نکنید به جای پرداخت اصل پول (و حرکت رو به جلو) باید سود و بهره (اصلاح نقص‌ها) را هم بپردازید.
سعی نکنید مشتریان خود را قفل کنید. بگذارید اطلاعات مورد نیازشان را وقتی که به آنها احتیاج دارند و هر طور که دوست دارند به دست آورند. برای این کار باید فکر بستن درزهای خروج اطلاعات را کنار بگذارید. برعکس، بگذارید داده‌ها آزادانه منتشر شوند. اجازه بدهید افراد به اطلاعاتشان از طریق RSS دسترسی داشته باشند. رابط‌های برنامه‌نویسی (API) ارائه کنید و بگذارید برنامه‌نویسان بر مبنای برنامه شما برخی ابزار را بسازند. وقتی این کار را بکنید، زندگی را برای مشتری‌های خود بهتر می‌کنید و امکانات برنامه خود را گسترش می‌دهید.
مردم طبق عادت فکر می‌کنند RSS فقط روشی برای دنبال کردن بلاگ‌ها و سایت‌های خبری است. قدرت RSS خیلی بیشتر از این‌ها است. آنها امکان بزرگی به مشتریان می‌دهند، مشتری‌ها می‌توانند بدون این که مرتباً به سایت وارد شوند، از تغییرات برنامه آگاه شده و بروز بمانند. با خوراک‌های Basecamp، مشتری‌ها می‌توانند یک آدرس را در خبرخوان وارد کنند و پیام‌های پروژه، فهرست کارها و فرسنگ‌شمارها را دنبال کنند، بدون این که مجبور باشند مرتباً سایت را ببینند.
رابط‌های برنامه‌نویسی به برنامه‌نویسان اجازه می‌دهد برای برنامه شما وصلینه‌هایی بنویسند که ممکن است به چیزهای بسیار گران‌قیمتی تبدیل شود. برای نمونه Backpack یک رابط برنامه‌نویسی دارد که شرکتChipt Production با استفاده از آن یک چیزک برای داشبورد Mac OS X ساخت. این چیزک به افراد امکان می‌دهد که از دسکتاپ خود یادآور اضافه یا اصلاح کنند، فهرست یادآورها را ببینند و ... مشتری‌ها شیفته آن چیزک شدند و حتی بعضی از آنها گفتند که مهم‌ترین انگیزه آنها برای استفاده از Backpack بوده است.
چند مثال خوب دیگر از شرکت‌هایی که اجازه می‌دهند داده‌ها رها شوند و بعد مثل بومرنگ دوباره به سوی آنها برگردند:
یک ویجت باعث تفاوت می‌شود
وقتی 37Signals مدت‌ها قبل Backpack را عرضه کرد، اولین واکنش من «اِی ...» بود. تقریباً همان زمانی که Chipt Production یک ویجت مخصوص Backpack برای Tiger عرضه کرد که ارزش بارگذاری و استفاده را داشت، نگاهی دوباره به Backpack انداختم. نتیجه؟ یک تفاوت بزرگ.
حالا هر وقت ایده‌ای به ذهنم می‌رسد، ویجت را باز می‌کنم، می‌نویسم و ثبت می‌کنم و ... تمام. آیا رایانامه‌ای رسیده که باید آن را بررسی کنم؟ ویجت را باز می‌کنم، می‌نویسم و ثبت می‌کنم و ... تمام. این ویجت جزو ضروریات هر رایانه مک‌ی است که من استفاده می‌کنم. و از آن جایی که هر چیزی وبی است، نیازی به کنترل کردن نسخه‌ها و همروند کردن نیست. فقط جریان سیالی از محتوا که اصلاً مهم نیست از کجا آمده است و این که در آینده چطور به آنها دسترسی خواهم داشت.
Todd Dominey، بنیانگذار Dominey Design (نقل از استفاده از Backpack)
