نرم‌افزاری که کار می‌کند، لزوماً نرم‌افزار خوبی نیست
یکی از چیزهایی که در طول سال‌ها کار با نرم‌افزار برایم روشن شده، تفاوت بین چیزی است که صرفاً کار می‌کند و چیزی که واقعاً می‌شود روی آن حساب کرد.
ساختن نسخه‌ای که یک نیاز را برطرف کند، همیشه مهم است؛ اما ماجرا به همان‌جا ختم نمی‌شود. سؤال اصلی وقتی شروع می‌شود که تعداد کاربران بیشتر شود، نیازها تغییر کنند، یک قابلیت جدید به محصول اضافه شود یا قرار باشد شخص دیگری کدهای نوشته‌شده را توسعه بدهد.
در چنین شرایطی، تصمیم‌هایی که روز اول ساده و کم‌اهمیت به نظر می‌رسیدند، ممکن است به دردسرهای جدی تبدیل شوند. منطق کسب‌وکار پراکنده در چند جای مختلف، کنترلرهایی که مسئولیت‌های زیادی به دوش می‌کشند، وابستگی‌های بی‌دلیل و تغییراتی که هر بار یک بخش دیگر را از کار می‌اندازند، معمولاً یک‌شبه به وجود نمی‌آیند. نتیجه‌ی مجموعه‌ای از انتخاب‌های کوچک‌اند که هرکدام در زمان خودشان منطقی به نظر رسیده‌اند.
البته منظورم این نیست که هر پروژه‌ای باید از روز اول پیچیده‌ترین معماری ممکن را داشته باشد. اتفاقاً به نظرم این هم یکی از اشتباهات رایج است؛ ساختن سیستمی که برای نیازهای احتمالی چند سال آینده آماده شده، در حالی که هنوز معلوم نیست محصول در شکل فعلی‌اش چه جایگاهی پیدا می‌کند.
معماری خوب، از نظر من، یعنی انتخاب راه‌حلی که با نیاز امروز تناسب داشته باشد و برای تغییرات قابل پیش‌بینی فردا هم دست ما را نبندد. نه اینکه برای هر احتمال دوری از همین حالا هزینه کنیم، نه اینکه برای سریع‌تر تمام کردن کار، آینده‌ی محصول را کاملاً نادیده بگیریم.
این نگاه فقط به بک‌اند و دیتابیس محدود نیست. رابط کاربری، امنیت، سرعت، مدیریت خطا، پشتیبان‌گیری و حتی نحوه‌ی استقرار نرم‌افزار، همگی بخشی از تجربه‌ی واقعی کاربرند؛ حتی اگر کاربر هیچ‌وقت از وجودشان باخبر نشود.
من معمولاً وقتی یک قابلیت را بررسی می‌کنم، فقط به این فکر نمی‌کنم که چطور آن را پیاده‌سازی کنم. سعی می‌کنم بفهمم اگر درخواست نامعتبر بود چه اتفاقی می‌افتد، اگر ارتباط قطع شد چه می‌شود، اگر حجم داده بالا رفت چه چیزی تغییر می‌کند و اگر شش ماه بعد قرار شد این بخش توسعه پیدا کند، چقدر هزینه خواهیم داد.
این پرسش‌ها شاید در نگاه اول سرعت توسعه را کم کنند، اما بسیاری از آن‌ها جلوی بازنویسی‌ها و مشکلاتی را می‌گیرند که بعداً هزینه‌ی بسیار بیشتری دارند.
برای من، برنامه‌نویسی فقط رساندن یک قابلیت به مرحله‌ی اجرا نیست. مسئولیت ما این است که چیزی بسازیم که علاوه بر امروز، در برابر تغییرات فردا هم تا جای ممکن قابل اتکا بماند.
کد خوب لزوماً کدی نیست که پیچیده‌تر نوشته شده یا از ابزارهای بیشتری استفاده می‌کند. گاهی بهترین تصمیم، همان راه‌حل ساده‌ای است که مسئله را درست حل می‌کند و نگهداری‌اش هم دشوار نیست.
به نظرم کیفیت واقعی نرم‌افزار را نه فقط در روز انتشار، بلکه در تغییر بعدی آن می‌شود شناخت.