گاهی به نظر می‌رسد که دولوپرها هدف اصلی تولید نرم‌افزار، که حل مسائل دنیای واقعی است، را به دست فراموشی سپرده‌اند! پنجاه سال پیش و در سال ۱۹۶۸، یک گردهمایی مهندسی نرم‌افزار با حمایت مالی NATO Science Committee برگزار شد که به طور کلی در آن زمان نرم‌افزار داشت اندک‌اندک به بخشی از زندگی روزمرهٔ مردم عادی تبدیل می‌شد؛ با این حال هنوز هم مقولهٔ بسیار پیچیده‌ای به شمار می‌آمد اما پس از این گردهمایی بود که برنامه‌نویسی شروع به خروج از حالت تجارت محض و تبدیل شدن به یک صنعت کاربردی نمود. صرف‌نظر از اینکه از آن زمان تاکنون برنامه‌نویسی چه مسیری را پشت سر گذاشته است، هنوز هم تفکیک تجارت نرم‌افزار از صنعت نرم‌افزار به راحتی امکان‌پذیر نیست و همین موضوع سبب می‌شود تا برخی دولوپرها با تمرکز بیش از حد بر توسعهٔ نرم‌افزار، به کلی فراموش کنند که هدف اصلی از تولید نرم‌افزار چیست و بدین ترتیب نتوانند به راه‌حل‌هایی بیندیشند که نیاز به نوشتن هیچ کدی ندارند!
هر کدی ارزش نوشتن ندارد!
استارتاپی را تصور کنید که در حال ساخت اپلیکیشنی است که باز کردن درب منزل را با استفاده از بلوتوث تلفن همراه برای افراد امکان‌پذیر می‌کند. رابط کاربری این اپلیکیشن ویجتی است که حتی در حالت قفل بودن تلفن، بر روی صفحه نشان داده می‌شود که این رابط تنها یک کلید تحت عنوان «باز کردن درب» دارد. هنگامی که کاربر به خانه نزدیک می‌شود، تلفن خود را از جیبش خارج می‌کند، ویجت را پیدا کرده و دکمهٔ باز کردن درب را تاچ می‌کند اما با دقت به پروسه، ممکن است این سؤال مطرح شود که اگر داریم از بلوتوث استفاده می‌کنیم، کسی که گوشی تلفنش را با خود به همراه دارد به سادگی می‌تواند با استفاده از بلوتوث گوشی خود درب را باز کند و دیگر اساساً چه نیازی هست که گوشی خود را در دست بگیرد و کلید باز کردن درب را فشار دهد و آیا بهتر نیست با رسیدن فرد به فاصلهٔ یک متری منزل، درب خودبه‌خود باز شود؟ که بدین ترتیب دیگر نیازی به هزینه کردن برای طراحی و کدنویسی یک اپ اختصاصی برای این کار نیز وجود نخواهد داشت.
به طور کلی، در اینجا هدف این است که درب منزل با کمترین تلاش ممکن باز شود و با کمی دقت دریافتیم که اگر حسگرها بی‌سیم باشند، وجود رابط کاربری برای این اپلیکیشن بی‌معنا خواهد بود و این مثال نشان می‌دهد که با در نظر داشتن هدف کار و مد نظر قرار دادن نیازهای واقعی کاربر، می‌توانیم دانش کاربر را به دانش خود افزوده به راه‌حل‌های ساده‌تر و بهتری دست پیدا کنیم (این مثال بسیار خوبی از چگونگی حل مسائل برنامه‌نویسی بدون کدنویسی بیشتر است؛ با این حال این موضوع نباید به بهانه‌ای برای کوتاهی و کم‌کاری در کدنویسی و نوشتن کدهای ناقص و بی‌کیفیت، تبدیل شود.)
هر باگی ارزش برطرف کردن ندارد!
گاهی اوقات برطرف نمودن یک باگ پیچیده ذاتاً در اولویت قرار ندارد. ممکن است دخالت انسانی نسبت به برطرف نمودن یک باگ مشخص هزینهٔ کمتری داشته باشد و برای تشخیص اینکه چه کاری در اولویت است، باید نسبت هزینه/سود را در نظر داشته باشیم؛ به عبارت دیگر، ببینیم که یک باگ مشخص چه تعداد از کاربران را تحت‌تأثیر قرار می‌دهد و مشکلی که ایجاد می‌کند تا چه حد جدی است:
رابطهٔ شدت مشکل و اولویت برطرف نمودن آن را می‌توان در یک ماتریس دوبُعدی به نام ماتریس اولویت مورد بررسی قرار داد. همان‌طور که در تصویر فوق می‌بینیم، این ماتریس دیباگ نمودن قطعات مشکل‌زای کد را بر مبنای تعداد کاربران درگیر با مشکل و میزان جدیت مشکل، مشخص می‌کند.
درک سورس‌کد از هر چیزی مهم‌تر است!
مرسوم است که دولوپرها برای هر چیزی اسکریپت‌نویسی می‌کنند اما این در حالی است که برخی از تَسک‌ها اساساً نباید از طریق اسکریپت و به صورت خودکار اجرا شوند. در حقیقت، گاهی اوقات نیاز است تا مسائل در ساده‌ترین حالت ممکن توسط دولوپرها قابل‌درک باشند و اگر آن‌ها به به اصطلاح Abstract (انتزاعی) کنیم، کسی که سورس‌کد را می‌خواند به دردسر خواهد افتاد!
هر فیچری ارزش کد زدن ندارد!
شرکتی که برای تحویل کالا به مشتریان از حملونقل بین‌المللی استفاده می‌کند، قصد دارد طی پروژه‌ای اختصاصی یک سیستم تأیید هویت بسیار کامل، بی‌عیب‌ونقص و کاربرپسند را برنامه‌نویسی کند به طوری که مشتریان باید اطلاعات شخصی خود را در آن وارد کرده تا این اطلاعات توسط شرکت حملونقل تأیید شود؛ اما کم‌کم با نزدیک شدن به بازهٔ زمانی تعیین‌شده برای تحویل پروژه، آن‌ها به این نتیجه می‌رسند که ایجاد چنین چیزی اصلاً توجیه ندارد چرا که از یکسو مشتری برای تحویل کالای خریداری شده چاره‌ای جز ارائهٔ اطلاعات درست ندارد و از سوی دیگر اغلب مرورگرها از سیستم اعتبارسنجی استاندارد HTML پشتیبانی می‌کنند که به قدر کافی کارایی دارد.
علاوه بر این و در بدترین حالت ممکن، اگر مشتری از طریق سیستم موفق به اعتبارسنجی اطلاعات خود نشود، با پشتیبانی شرکت تماس می‌گیرد و به صورت دستی اعتبارسنجی اطلاعات او انجام خواهد شد و از همین روی صَرف وقت و هزینه برای ایجاد چنین قابلیتی نامعقول به نظر می‌رسد.
سخن پایانی
اگر به عنوان یک دولوپر مسئلهٔ اصلی پیش‌روی خود را به خوبی درک کنید، قادر خواهید بود تا با کدهای بهتری و گاهی هم بدون نوشتن هیچ کدی به حل مسأله بپردازید اما اگر دائماً به دنبال حل مشکل با کدنویسی باشید، ممکن است از هدف و نیاز اصلی غافل شده و نتوانید ایدهٔ خوبی ارائه دهید. در همین راستا ضرب‌المثلی هست که می‌گوید:
کسی که تنها ابزارش یک چکشه، همه‌چیز رو مثل یک میخ می‌بینه!
پس می‌بایست مراقب بود تا تنها ابزارمان کدنویسی نباشد و همواره باید سعی کنیم تا ابتدا مشکل را به درستی تشخیص داده، سپس ایدهٔ مناسبی ارائه دهیم و در پایان اگر نیاز بود، کد بزنیم. همچنین هرگز فراموش نکنید که شما صرفاً برای نوشتن کدهای بیشتر و بیشتر استخدام نشده‌اید؛ بلکه به عنوان یک متخصص استخدام شده‌اید تا مسائل و مشکلات را به بهترین نحو حل کنید و نیاز به توضیح نیست که گاهی اوقات مسائل حتی بدون کدنویسی نیز حل می‌شوند و در یک کلام در نظر داشته باشید که برای خودنمایی کردن کد نزنید بلکه هدف شما و هدف کدی که می‌نویسید این باید باشد که دنیا را به جای بهتری برای زندگی تبدیل نمایید.