وقتی باگ‌هامون بهمون ایده میدن

یه روز یه باگ ساده توی لاگ‌نویسی کل سرویس رو کند کرده بود.
فکر می‌کردم multi-threading قاتی کرده، ولی بعد از چند ساعت بررسی فهمیدم داستان یه چیز دیگه‌ست:
یه race condition باعث شده بود بخشی از لاگ‌ها به‌صورت async نوشته بشن — و جالبه که همین باعث کاهش محسوس latency شده بود!

اونجا بود که یه سؤال تو ذهنم اومد:

«اگه این رفتار اشتباهی رو کنترل کنم، می‌تونه تبدیل به یه فیچر واقعی بشه؟»

شروع کردم به بازنویسی همون باگ، ولی این بار آگاهانه.
نتیجه شد یه ماژول جدید برای async logging که الان تو چند تا سرویس اصلی داره کار می‌کنه.
همون باگی که قرار بود fix بشه، شد یه قابلیت جدید.

این فقط تجربه‌ی من نبود.
توی دنیای نرم‌افزار، بارها و بارها دیدیم که یه خطا، یه اشتباه یا یه رفتار غیرمنتظره تبدیل شده به چیزی بزرگ‌تر از خودش.

مثلاً:

• توی Slack، یه باگ باعث شد نوتیفیکیشن‌ها با تأخیر برسن.
  تیم به‌جاش تصمیم گرفت اون تأخیر رو هدفمند کنه و نتیجه شد Smart Delivery Delay.

• توی Twitter، یه خطای محدودیت کاراکتر باعث شد کاربرها بتونن متن‌ها رو نقل‌قول کنن؛ شد Quoted Tweet.

• توی Photoshop، یه اشتباه در مدیریت history شد نقطه‌ی شروع چیزی که امروز بدونش کار نمی‌کنیم: Undo.

همه‌ی این‌ها یه پیام مشترک دارن:
باگ‌ها فقط خطا نیستن — گاهی نشونه‌ی مرزهای جدیدن.
وقتی یه سیستم از کنترل خارج می‌شه، در واقع داره بهت نشون می‌ده که «یه مسیر جدید» هم وجود داره.

گاهی باید به‌جای panic یا quick fix، فقط یه لحظه وایسی و بپرسی:

«اگه این رفتار اشتباهی یه قابلیت بود، چه کاربردی می‌تونست داشته باشه؟»

خیلی از نوآوری‌های بزرگ، دقیقاً از همین سؤال ساده شروع شدن.

پایان

برنامه نویس باشید و ازش لذت ببرید.

میم جیم صاد