راه‌انداختن نرم‌افزار بهترین روش برای ایجاد نیروی محرک است. به گروهتان نیرویی تازه بدهید و ایده‌هایی را که به کار نمی‌آیند دور بریزید. این باید اولین اولویت شما از همان روز نخست باشد. کار کمتر کردن، نادیده گرفتن جزئیات، میانبر زدن در فرایند اگر منجر به عرضه سریعتر نرم‌افزار گردد، مطلوب و پسندیده است. وقتی به این مرحله رسیدید، پاداش شما منظره‌ای بسیار دقیق‌تر از روش ادامه کار است. داستان‌‌ها، ماکت ها، حتی نمونه‌های آزمایشی html فقط تقریب و تخمین هستند. نرم‌افزار در حال کار، واقعی است.
با کمک نرم‌افزار واقعی و در حال اجرا، هر کسی به درک درست از نرم‌افزار و تأیید آن نزدیک‌تر می‌شود. از بحث های داغ بر روی طرح ها و نوشته ها که هیچگاه به سرانجامی نمی رسند پرهیز می کنید. می‌فهمید که قسمت‌هایی که فکر می‌کردید جزئی و بی‌اهمیت هستند، در واقع بسیار مهم و حیاتی هستند.
چیزهای واقعی به واکنش‌های واقعی منجر می‌شوند، و این گونه است که شما به حقیقت می‌رسید.
چیز واقعی به موافقت منجر می‌شود
وقتی گروه‌های متفاوتی از افراد با کار بر روی مدل‌های و چیزهای واقعی، تلاش و فهم چیزی موزون را آغاز می‌کنند، دیدگاه‌شان درباره آن چیز به همگرایی متمایل می‌شود. اگر آنها طرح می‌زنند یا ایده می‌دهند، موافقتی جلب نمی‌کنند. اگر شما با ساختن چیزی واقعی آغاز کنید، آنها به موافقت با شما متمایل می‌شوند.
Christopher Alexander استاد معماری، نقل از (Contrasting Concepts of Harmony in Architecture)
هرچه سریعتر آن را به کار بیاندازید
من فکر نمی‌کنم که هیچگاه در یک پروژه نرم‌افزاری که در زمانبندی یا هزینه یا قابلیت‌های مورد نظر در ابتدای کار و با برنامه‌ریزی و مباحثات بلند مدت و بدون توسعه همزمان، موفق بوده، حضور داشته‌ام. خیلی ساده و گاهی اوقات خنده‌دار است که وقت باارزش خود را در ساختن ویژگی‌هایی که نالازم یا پیادهسازی نشدنی هستند، هدر می‌دهیم.
این مسأله شامل تمام سطوح توسعه می شود و «چیز واقعی ساختن و راه اندازی آن» مثل یک فرکتال است. فقط شامل کل پروژه نیست. بلکه اجزای کوچکتر توسعه، مثل مؤلفه هایی که در ساخت برنامه از آن ها استفاده می شود را هم شامل می شود.
وقتی یک پیاده سازی در حال کار از یک مؤلفه اصلی وجود داشته باشد، برنامه نویس ها می خواهند هر چه سریعتر بفهمند که این مؤلفه با قسمتی از برنامه که در حال توسعه آن هستند کار می کند یا نه و معمولاً سعی می کنند هر چه زودتر از آن استفاده کنند. حتا اگر در ابتدا پیاده سازی کامل یا خوب نباشد، این همکاری زود هنگام معمولاً به رابط های خوش تعریف و ویژگی هایی که آنها واقعاً به آن نیاز دارند، رهنمون می شود.
Matt Hamer، توسعه دهنده و مدیر محصول، Kinja
انتظار نداشته باشید که در همان ابتدای کار همه چیز را بدانید. بگذارید برنامه رشد کند و با شما سخن بگوید. بگذارید تغییر بکند و بزرگ شود. در دنیای وب دیگری نیازی نیست محصولی عالی برای مشتری ارسال شود. صفحات را طراحی کنید، از آنها استفاده کنید، آنها را تحلیل کنید و باز مجدداً آغاز کنید.
طراحی تکراری به شما اجازه می‌دهد به جای تلاش برای به دست آوردن همه چیز از همان ابتدا، در طول کار بتوانید تصمیم‌های آگاهانه‌ای بگیرید. علاوه بر این، به خاطر این که تلاش شما برای ارائه محصولی کامل نیست، سریعتر به برنامه‌ای فعال و در حال اجرا دست می‌یابید. نتیجه این کار بازخورد واقعی و راهنمایی‌های واقعی درباره چیزهایی است که به توجه شما نیاز دارند.
تکرارها منتج به آزادی می‌شود
اگر می‌دانید که در هر صورت باید در آینده کاری را مجدداً تکرار کنید، نیازی نیست در اولین تلاش‌ها برای کسب کمال تلاش کنید. دانستن این که موضوعی را باید بازبینی کنید انگیزه‌ای قوی برای آزمودن ایده‌ها و دیدن پایداری آنها است.
ممکن است شما از من باهوش‌تر باشید
شاید شما بسیار باهوش‌تر از من باشید. کاملاً ممکن است. در واقع محتمل است. بنابراین اگر شما هم شبیه اغلب مردم هستید، پس مثل من در تصور چیزهایی که نمی‌توانید ببینید یا حس کنید یا لمس کنید مشکل دارید.
آدم‌ها در پاسخ به اشیاء محیط بسیار خوب هستند. ما می‌دانیم که وقتی ببری وارد اتاق می‌شود چگونه باید بترسیم، و پس از سیلی ویرانگر چگونه باید همه چیز را پاک و تمیز کنیم. متأسفانه ما در برنامه‌ریزی آینده و در فهم شاخه‌های مختلف اعمالمان و اولویت‌بندی چیزهایی که واقعاً مهم هستند، بسیار بد عمل می‌کنیم.
شاید شما جزو تعداد کم از افراد باشید که می‌توانید همه چیز را در ذهن خود نگهداری کنید. این مسأله اصلاً مهم نیست.
وب 2، با فرض این که الأن همه از وب استفاده می‌کنند، جایی است که برنامه‌نویسان باهوش کاری می‌کنند که ضعف‌های انسانی برایشان کار کند. چطور؟ با اجازه دادن دادن به کاربران برای بیان آنچه که فکر می‌کنند، در حالی که هنوز آن قدر فرصت هست تا درباره آنها کاری انجام داد.
و آن آخرین جمله علت این است که باید به این شیوه برنامه‌نویسی کنید و چگونگی ترویج و عرضه را توضیح می‌دهد.
داستان خود را صریح و بی‌پرده بیان کنید. مطمئن شوید که همه اجزا درست کار می‌کنند. بعد از آن نرم‌افزار را عرضه و بازبینی کنید.
هیچکس باهوش تر از همگان نیست.
Seth Godin، نویسنده و کارآفرین
فرایند واقعی شدن ما اینگونه است:
با ایده‌ها شروع کنید. این محصول قرار است چه کار کند؟ درباره Basecamp ما به نیازهای خودمان نگاه کردیم. می‌خواستیم اصلاحات پروژه‌ها را برای هم بفرستیم. می‌خواستیم مشتری‌ها در کار مشارکت کنند. می‌دانستیم که پروژه‌ها فرسنگ‌شمار دارند. می‌خواستیم بایگانی‌ها را متمرکز کنیم تا هر کسی خواست به چیزهای قدیمی دسترسی داشته باشد، بتواند. می‌خواستیم چشم‌اندازی بزرگ به چیزهایی که در هر پروژه می‌گذشت داشته باشیم درست مانند پرنده‌ای که از بالا به همه چیز می‌نگرد. همه آن فرض‌ها و چندتای دیگر، پایه کار ما شدند.
این مرحله درباره جزئیات چرت و پرت نیست، درباره پرسش‌های بزرگ است. چنین جزئیاتی در این مرحله بی‌معنی هستند.
طرح‌های اولیه سریع، کثیف و بی‌ارزش هستند و این همان چیزی است که برای شروع نیاز دارید. چیزهای مختلف را بکشید. آنها را خرچنگ قورباغه بنویسید. کادرها، دایره‌ها و خط‌ها. ایده‌ها را از فکر خود به کاغذ منتقل کنید. در این مرحله هدف، تبدیل مفاهیم به طراحی نماهای نامرتب است. این مرحله کلاً درباره آزمودن است. هیچ پاسخ اشتباهی وجود ندارد.
نسخه‌ای HTML از آن ویژگی (یا بخش یا جریان، هر کذام که مناسب‌تر است) بسازید. چیزی واقعی را آماده کنید تا افراد بفهمند که طرح بر روی نمایشگر چگونه خواهد شد. برای Basecamp، ما اول صفحه «ارسال پیام» و بعد از آن «ویرایش پیام» را ساختیم و از همانجا کار را ادامه دادیم. هیچ کدی در این مرحله ننویسید. فقط با HTML و css نمونه و ماکت بسازید. پیادهسازی برای مراحل بعدی است.
هر زمان که ماکت آماده شد و کارایی‌های مورد نظر را به خوبی نمایش داد، به سراغ برنامه‌نویسی بروید و آن را ضمیمه کنید. در تمام طول مدت این فرایند، به خاطر داشته باشید که منعطف بمانید و انتظار چندین بار تکرار را داشته باشید. باید آماده باشید محصول نهایی هر مرحله را اگر بد شده بود، دور بریزید و مجدداً از اول شروع کنید. کاملاً طبیعی است که همه این چرخه را چندین بار تکرار کنید.
با پرسش سختی روبرو شده‌اید: چند پیام را در هر صفحه نمایش می‌دهیم؟ گرایش اول شما این است که بگویید: «بیایید آن را در ترجیحات قرار دهیم تا هر کسی بتواند 25 یا 50 یا 100 را انتخاب کند». این روش راه فراری ساده است. به جای آن، تصمیمی بگیرید.
ترجیحات راهی برای دوری کردن از اخذ تصمیمات سخت است
به جای استفاده از مهارت خود در یافتن راه مناسب، کار را به مشتریان می‌سپارید. به نظر می‌رسد که شما دارید به آنها لطف می‌کنید، ولی فقط سر آنها را شلوغ‌تر می‌کنید (در حالی که احتمالاً به اندازه کافی سرشان شلوغ است). صفحات ترجیحات برای کاربران بیشتر به سردرد شبیه است تا نعمت و موهبت. مشتریان نباید درباره جزئیات چرت و پرت فکر کنند. این بار سنگین را که جزو وظایف شما است، بر گردن مشتریان نیاندازید.
همچنین ترجیحات از آنجایی که نرم‌افزار بیشتری تولید می‌کنند، زیان‌آور هستند. اختیارات بیشتر به کد بیشتر نیاز دارند. همچنین باید آزمون و طراحی فوق‌العاده اضافه‌ای نیز انجام دهید. در انتها نیز با جایگشت‌های مختلف این اختیارات مواجه می‌شوید و صفحاتی که در حین طراحی هرگز آنها را ندیده‌اید. این یعنی خطاهایی که چیزی درباره آنها نمی‌دانید: چیدمان صفحه به هم ریخته، جدول‌های درهم رفته، مسائل عجیب و غریب درباره صفحه‌بندی و غیره.
به جای مشتریان خود، تصمیم‌های ساده‌ای بگیرید. در Basecamp ما همین کار را کردیم. تعداد پیام‌ها در هر صفحه 25 تا است. در صفحه «برداشت کلی» 25 عنوان آخر نمایش داده می‌شود. پیام‌ها بر اساس معکوس زمان مرتب می‌شوند. 5 پروژه فعال آخر در داشبورد نمایش داده می‌شوند. هیچ اختیاری وجود ندارد. فقط همانی است که هست. قبول، ممکن است که تصمیم بدی بگیرید. ولی اشکالی ندارد. اگر اینگونه باشد، مردم اعتراض می‌کنند و درباره آن با شما صحبت می‌کنند. شما هم مثل همیشه می‌توانید تصمیم خود را تعدیل کنید. در کل واقعی شدن درباره توانایی تغییر در لحظه است.
ترجیحات هزینه دارد
مشخص است که ترجیحات هزینه دارد. درست است که برخی ترجیحات هم مزایای زیادی دارند و ممکن است جزو ویژگی‌های ضروری طراحی باشند. ولی هر کدام قیمتی دارند و باید به دقت ارزش آن را بررسی کنید. بسیاری از برنامه‌نویسان و کاربران این موضوع را درک نمی‌کنند و در انتها بابت چیزی کم ارزش دلارهای زیادی می‌پردازند... فهمیدم که اگر به جای ترجیحاتی که به کندی اضافه می‌شوند، نسبت به پیش‌فرض‌هایی که کار می‌کنند سر سخت و متعصب باشید، کل نمای کاربری به صورت طبیعی به مسیر صحیح هدایت می‌شود.
Havoc Pennington، سرپرست فنی، Red Hat (نقل از Free software and good user interfaces)
عمل کنید. به این کلمه جادویی فکر کنید. وقتی می‌خواهید عمل کنید یعنی این که چیزی به انجام رسیده است. تصمیمی گرفته شده است و شما می‌توانید حرکت کنید. عمل کردن یعنی این که شما نیروی محرکه می‌سازید.
ولی صبر کنید، اگر تصمیم اشتباه گرفتید و گند زدید چه؟ مشکلی نیست. جراحی مغز که نمی‌کنید، برنامه وب می‌نویسید. همانطور که همیشه گفته‌ایم در هر صورت احتمالاً چندین بار ویژگی‌ها و ایده‌ها را در طول کار، باید بازبینی کنید. بدون توجه به این که چقدر برنامه‌ریزی کرده‌اید، همیشه نیمی از کارهای شما اشتباه است. پس «سکته حین تحلیل» نکنید. این کار فقط فرایند را کند می‌کند و روحیه را از بین می‌برد. بر عکس، به حرکت و حرکت رو به جلو ارزش بدهید. با فرایند تصمیم گیری همنوا بشوید. تصمیمی سریع و آسان بگیرید و بعد اگر کار نکرد، برگردید و آن را تغییر دهید. بپذیرید که تصمیم‌ها موقت و زودگذر هستند. بپذیرید که خطاها رخ می‌دهند و بدانید تا وقتی که می‌توانید آنها را به سرعت اصلاح کنید، چیزهای مهمی نیستند. اجرا کنید، نیروی محرک ایجاد کنید و حرکت کنید.
اجرا کننده باشید
خیلی خنده‌دار است که می‌بینم مردم چطور از ایده‌هایشان محافظت می‌کنند. (افرادی که از من می‌خواهند nda (موافقت‌نامه حفظ اسرار) را امضا کنم تا ساده‌ترین ایده‌ها را به من بگویند.) در نظر من ایده‌ها تا اجرا نشوند، هیچ ارزشی ندارند. آنها فقط یک ضریب هستند، در حالی که آن چیزی که میلیون‌ها می‌ارزد، اجرا است.
توضیح:
- ایده وحشتناک = 1-
- ایده ضعیف = 1
- ایده نه خوب و نه بد = 5
- ایده خوب = 10
- ایده عالی = 15
- ایده فوق‌العاده = 20
- اجرا نکردن = 1 دلار
- اجرای ضعیف = 1000 دلار
- اجرای نه خوب و نه بد = 10.000 دلار
- اجرای خوب = 100.000 دلار
- اجرای عالی = 1.000.000 دلار
- اجرای فوق‌العاده = 10.000.000 دلار
برای داشتن یک کسب و کار، این دو را باید ضرب کنید. فوق‌العاده‌ترین ایده، بدون اجرا فقط 20 دلار می‌ارزد. فوق‌العاده‌ترین ایده با اجرای فوق‌العاده بیست میلیون دلار می‌ارزد.
به این دلیل است که دوست ندارم ایدههای مردم را بشنوم. تا وقتی هیچ اجرایی نبینم، علاقه‌ای به آنها ندارم.
Derek Sivers، رئیس و برنامه‌نویس، CD Baby و Host Baby
هیچ جانشینی برای افرادی واقعی که از برنامه استفاده واقعی می‌کنند وجود ندارد. داده‌های واقعی جمع کنید، بازخوردهای واقعی تهیه کنید، سپس بر اساس آن اطلاعات برنامه را بهبود دهید. آزمون کاربرد صوری، خیلی رسمی و خشک است. تنظیمات آزمایشگاهی واقعیت را منعکس نمی‌کنند. اگر بر روی شانه‌های کسی بایستید، ایدههای از چیزهایی که کار می‌کنند و کار نمی‌کنند به دست می‌آورید ولی مردم معمولاً جلوی دوربین خوب کار نمی‌کنند. وقتی شخص دیگری در حال تماشا است، مردم به شدت مراقب هستند که هیچ اشتباهی مرتکب نشوند و حال آن که چیزی که شما دنبال آن هستید همین اشتباهات است.
به جای آن، نسخه بتا ویژگی‌های جدید را برای تعدادی از افراد برگزیده از میان کاربران نرم‌افزار واقعی عرضه کنید. آنها را وادارید که از ویژگی‌های بتا در کنار ویژگی‌های عرضه شده استفاده کنند. این کار آنها را در معرض داده‌های واقعی و جریان‌های کار واقعی افراد قرار می‌دهد. و اینجا است که شما نتایجی واقعی به دست می‌آورید.
توضیح بیشتر این که نسخه عرضه شده و نسخه بتا مجزا نداشته باشید. بهتر است هر دوی آنها یکی باشند. نسخه بتا مجزا چیزی کاملاً صوری است. نسخه اصلی به همراه تعدادی ویژگی‌های بتا که در آن تعبیه شده است، نتیجه خوبی به دست می‌دهد.
کتاب بتا
اگر برنامه‌نویسان از عرضه کد عصبی می‌شوند، نویسندگان و ناشران از عرضه کتاب وحشت‌زده می‌شوند. وقتی کتابی به کاغذ منتقل شد، تغییر دادن آن کار حضرت فیل است. (البته واقعیت این نیست ولی ذهنیات و خاطره‌های مشکلات فناوری‌های قدیمی، هنوز در صنعت باقی مانده و آن را کند نگه داشته است.) بنابراین ناشران کلی دردسر می‌کشند (و هزینه می‌پردازند) تا کتاب را قبل از عرضه، تصحیح کنند.
وقتی که کتاب «توسعه وب چابک با Rails» را می‌نوشتم، مطالبات فراوانی در بین برنامه‌نویسان بود: کتاب را همین الأن به ما بدهید، ما می‌خواهیم Rails را یاد بگیریم. ولی من درگیر دهنیت ناشرها بودم :«هنوز آماده نیست». ولی فشار اعضای جامعه و تحریک‌های David Heinemeier Hansson دیدگاه مرا عوض کرد. ما نسخه‌ای از کتاب را حدود دو ماه قبل از این که کامل شود به صورت pdf منتشر کردیم. نتایج دیدنی بود. نه تنها این که کتاب بسیار فروش کرد، بازخوردهای زیادی نیز گرفتیم. سامانه‌ی خودکاری را برای دریافت نظرات خوانندگان تنظیم کردم و در انتهای کار حدود 850 گزارش و نکته و خطاهای فنی و پیشنهاد برای محتوای جدید جمع‌آوری شد. تقریباً همه آنها در نسخه نهایی کتاب اعمال شد.
معامله‌ای برنده-برنده بود. من کتاب چاپی بهبود یافته‌ای داشتم و اعضای جامعه هم زودتر به چیزی که نیاز داشتند رسیدند. و اگر شما در حال مسابقه دادن هستید، بیرون دادن سریع چیزی، باعث می‌شود افراد به کمک شما بیایند و نه این که رقیب شما بشوند.
Dave Thomas، از The Pragmatic Programmer
به سرعت انجام بده
تصمیم بگیر که آیا ارزش انجام دادن دارد یا نه؟ اگر دارد: به سرعت انجامش بده. نیازی نیست عالی باشد، فقط انجامش بده. ذخیره کن، بارگیری کن، منتشر کن. ببین نظر مردم چیست.
با وجود آنکه من معمولاً میلی به افزودن ویژگی‌های جدید به چیزی ندارم ولی لحظه‌ای که ببینم چیزی ارزشش را دارد، آن چیز در کمتر از چند ساعت در سایت بالا می‌آید. معیوب و ناقص ولی عرضه شده است. می‌گذارم بازخوردهای آینده آن را تصحیح کند.
Derek Sivers، رئیس و برنامه‌نویس، CD Baby و HostBaby
تخمین‌ها و برآوردهایی که هفته‌ها یا ماه‌ها طول می‌کشد، اوهام و خیالات است. واقعیت این است که شما پیشاپیش نمی‌دانید که در آن زمان‌های دور چه اتفاقاتی خواهد افتاد.
بنابراین زمان را کوتاه‌تر کنید. زمان را به قطعات کوچک‌تری تقسیم کنید. به جای یک پروژه 12 هفته‌ای، به دوازده پروژه یک هفته‌ای فکر کنید. وظایفی را که بیش بر اساس حدس و تخمین بیش از 30 ساعت طول می‌کشد، به موارد واقعی کوچکتر، بین 6 تا 10 ساعته تقسیم کنید. سپس در هر زمان یک قدم به جلو حرکت کنید.
فرضیه‌ای مشابه، برای همه مسائل کاربرد دارد. آیا شما با مسأله‌ای مواجهید که تمام ذهن شما را به خود مشغول کرده است؟ به قطعات کوچکتر تقسیم‌اش کنید. مسائل را همچنان کوچکتر و کوچکتر کنید تا جایی که بتوانید آنها را هضم کنید.
وظایف کوچکتر و گاه‌شمارهای کوچکتر
برنامه‌نویس‌ها یک جور خاصی خوش‌بین هستند، وقتی کاری درباره برنامه‌نویسی به آنها پیشنهاد می‌شود، فکر می‌کنند «خیلی آسان است! اصلاً زمانی نمی‌برد!». بنابراین به یک برنامه‌نویس سه هفته وقت بدهید تا یک وظیفه بزرگ را به انجام برساند. دو هفته و نیم آن را از کار طفره می‌رود و کار را به تأخیر می‌اندازد و بعد یک هفته برنامه می‌نویسد. نتایج خارج از برنامه زمانی احتمالاً با نیازمندی‌‌های اشتباه مواجه می‌شوند، زیرا آن وظیفه بسیار پیچیده‌تر از آن چه که به نظر می‌رسید از کار در می‌آید. به علاوه، چه کسی به یاد می آورد که سه هفته پیش گروه به چه توافقاتی رسیده بود؟
به برنامه‌نویس یک بعد از ظهر وقت بدهید تا یک قسمت خاص و کوچک را برنامه‌نویسی کند. او نیز آن را نوشته و برای حرکت به قسمت بعدی آماده می‌شود. وظایف کوچکتر و گاه‌شمارهای کوچکتر بهتر مدیریت می‌شوند، فهمِ غلطِ نیازمندی‌‌ها را کمتر مخفی می‌کند و هزینه تغییر دیدگاه شما و برگشت کارها را کم می‌کند. گاه‌شمارهای کوچکتر برنامه‌نویسان را متعهد می‌کند و به آنها فرصت می‌دهد تا از احساس به انجام رساندن چیزی لذت ببرند و کمتر به این فکر کنند که: «اوه! خیلی برای این کار وقت گذاشتم، الأن باید رتبه‌بندی آهنگ‌هایم در کتابخانه iTunes را کامل کنم».
Gina Trapani، برنامه‌نویس وب و ویراستار Lifehacker، راهنمای بهره‌وری و نرم‌افزار
عوامل مؤثر واقعی
دفعه بعدی که یک نفر با اصرار از شما خواست که پاسخی دقیق به پرسشی نامشخص بدهید (خواه درباره تاریخ ضرب‌الاجل، هزینه نهایی پروژه، یا این که چقدر شیر برای پر کردن Grand Canyon لازم است)، نفس خود را بیرون بدهید و بگویید: «نمی‌دانم». نگران اعتبار خود نباشید، این کار نشان دهنده دقتی است که در تصمیم‌گیری دارید. لازم نیست برای باهوش نمایاندن خود چیزی بگویید. همچنین این کار با تبدیل سؤال به یک گفتگوی مشترک، زمینه بحث را آماده می‌کند. با آموختن این که تخمین‌‌های شما چقدر باید صیحیح باشد (و چرا)، می‌توانید مشترکاً بر روی فهم مشترک عوامل مؤثر واقعی، که پشت اعداد و ارقام هستند، کار کنید.
Merlin Mann، بنیانگذار و ویرایشگر 43Folders.com
مسأله‌ای را حل کنید که به شما خیره شده است
تنها چیز محبوب و دوست داشتنی که در وب اتفاق افتاده و به یاد می‌آورم، عرضه و پذیرش ویژگی «دنبالم نکن (nofollow)» است. هیچکس قبلاً درباره آن صحبت نکرده است. هیچ کنفرانس یا اتحادیه‌ای که یک مشت آدم وراج درباره معنا شناخت و صرف و نحو آن صحبت کنند وجود نداشته است. هیچ «درخواست توضیحات» که می تواند یک ایده ساده را به یک قطعه XML 20 خطی تبدیل کند که برای فهمیدن نحوه استفاده از آن چاره ای جز خواندن آن نیست و بعد هم نمی توانم از آن استفاده کنم چرا که مطمئن نیستم باید برای نسخه 3 فرمت بندی کنم یا 3.3b.
ساده است، مؤثر است. راه چاره ای است برای کسانی که حق انتخاب می خواهند و از همه مهم تر اینکه در وب با جمعیت انبوهی سر و کار داریم که به ویژگی های مستند شده اهمیت نمی دهند و احترام نمی گذارند.
بعضی اوقات حل کردن بیست مسأله بعدی به اندازه حل کردن آن یکی که مستقیم به چشم های ما خیره شده مفید یا معقول نیست. این فقط یک پیروزی کوچک در برابر هرزنامه ها نیست (همه پیروزی ها در برابر هرزنامه ها، کوچک هستند)، بلکه یک پیروزی برای ماهایی است که از نتایج ساده و سریع لذت می بریم. این کار اصلی یک توسعه دهنده وب است.
Andre Torrez، برنامه نویس و نایب رئیس Engineering at Federated Media Publishing
