یہ بگ نہیں، یہ فیچر ہے — معنی، ابتدا اور فرق

«یہ بگ نہیں، یہ فیچر ہے» کا کیا مطلب ہے

«یہ بگ نہیں، یہ فیچر ہے» — ایک جملہ جو ڈویلپر یا مینیجر اس بات کی نشاندہی کرنے کے لیے استعمال کرتا ہے کہ پروگرام کا غیر متوقع رویہ جان بوجھ کر ہے، غلط نہیں۔ کلاسیکی صورت میں، یہ ایک مذاق ہے: سب سمجھتے ہیں کہ رویہ غلط ہے، لیکن تناؤ کم کرنے کے لیے اسے «فیچر» کہا جاتا ہے۔ تاہم، حقیقی منصوبوں میں، یہ جملہ سنجیدگی سے بھی استعمال ہوتا ہے — جب رویہ حقیقتاً تصریح سے مطابقت رکھتا ہو لیکن صارف کی توقعات پر پورا نہ اترتا ہو۔

بگ اور فیچر کے درمیان فرق اکثر ساپیکش ہوتا ہے۔ جس ڈویلپر نے کوڈ لکھا ہے، اس کے لیے ایک خاص رویہ منطقی لگ سکتا ہے۔ صارف کے لیے، یہ غیر متوقع اور غلط لگ سکتا ہے۔ ادراک کی ساپیکشیت بنیادی وجہ ہے کہ جملہ اتنا پائیدار ہے۔ یہ گفتگو کو «کس کا قصور ہے» سے «ایسا ڈیزائن کیا گیا تھا» میں منتقل کرتا ہے۔ UX Collective کے مطابق، صارفین کی طرف سے رپورٹ کردہ 40% بگ دراصل UX مسائل ہیں، کوڈ کی غلطیاں نہیں۔

فرتیلی ٹیموں میں، ڈیمو کے دوران یہ جملہ اکثر دفاعی طریقہ کار کے طور پر استعمال ہوتا ہے۔ ڈویلپر غیر متوقع رویہ دکھاتا ہے، پروڈکٹ اونر پیشانی سکوڑتا ہے، اور تقدیر کا جملہ «یہ بگ نہیں، یہ فیچر ہے» کہا جاتا ہے۔ ٹیم میں اعتماد یہ طے کرتا ہے کہ جملے کو مذاق کے طور پر لیا جائے گا یا مسئلہ چھپانے کی کوشش کے طور پر۔ صحت مند ٹیم میں، ایسا مذاق ماحول کو ہلکا کرتا ہے، زہریلی ٹیم میں — تنازع کا سبب بنتا ہے۔

مشہور جملے کے ظہور کی تاریخ

جملے کا پہلا معروف استعمال 1976 میں DECUS (ڈیجیٹل ایکوئپمنٹ کارپوریشن یوزر سوسائٹی) کے بلیٹن میں ریکارڈ کیا گیا۔ ایک صارف نے شکایت کی کہ RUNOFF ٹیکسٹ پروسیسر خالی سطروں کو غلط طریقے سے ہینڈل کرتا ہے۔ ڈویلپر کا جواب: «یہ بگ نہیں، یہ فیچر ہے — پیراگراف اسی طرح پروسیس ہوتے ہیں۔» اس کے بعد سے، یہ جملہ اپنی اصل کیفیت سے قطع نظر، «جیسا ہے ویسا» لکھے گئے کوڈ کے دفاع کی علامت بن گیا ہے۔

جملے کو مقبول بنانے میں Jargon File نے حصہ لیا — ہیکر سلیگ کی ایک لغت جو 1990 کی دہائی میں «The New Hacker’s Dictionary» کتاب کی بنیاد بنی۔ Jargon File میں، «feature» کا اندراج براہ راست ان بگز کی طرف اشارہ کرتا ہے جو ان کی اصلاح کی ناممکن یا ناپسندیدگی کی وجہ سے فیچر بن گئے۔ مثال: ابتدائی ٹرمینلز میں Caps Lock کی چابیاں میں کوئی اشارہ نہیں تھا — یہ ایک بگ تھا جو «آنکھ بند کر کے ٹائپنگ» کے لیے فیچر بن گیا۔

2000 کی دہائی میں، یہ جملہ انٹرنیٹ میمز کے ذریعے مقبول ثقافت میں منتقل ہوا۔ «It’s not a bug, it’s a feature» کے عنوان والی بلی کی تصویر فورمز اور سوشل میڈیا پر پھیل گئی۔ گیمنگ انڈسٹری میں، یہ جملہ خاص طور پر اکثر استعمال ہوتا ہے: گلیچز جو گیم پلے کو متاثر نہیں کرتے، ماحول کے لیے «فیچر» قرار دیے جاتے ہیں۔ ثقافتی رجحان IT سے بہت آگے پھیل گیا ہے — یہ جملہ کسی بھی سیاق و سباق میں سنا جا سکتا ہے جہاں غلطی کو جواز فراہم کیا جاتا ہے۔

بہانے کی نفسیات: کیوں کہا جاتا ہے

جملے کی نفسیاتی بنیاد علمی تضاد ہے۔ ایک ڈویلپر نے کوڈ لکھنے میں گھنٹوں گزارے ہیں، اور یہ تسلیم کرنا کہ نتیجہ غلط ہے اس کے کام کی قدر کم کرنا ہے۔ جملہ «یہ بگ نہیں، یہ فیچر ہے» تضاد کو کم کرتا ہے: غلطی ایک جان بوجھ کر کیے گئے فیصلے میں بدل جاتی ہے، اور ڈویلپر قصوروار سے خیال کے مصنف میں بدل جاتا ہے۔ یہ ایک نفسیاتی دفاعی طریقہ کار ہے جو خود اعتمادی کو برقرار رکھتا ہے۔

دوسری وجہ دوبارہ کام کا خوف ہے۔ بگ تسلیم کرنے کا مطلب ہے کوڈ ریویو، ٹیسٹنگ اور ڈپلائمنٹ پھر سے کرنا۔ «فیچر» کو اصلاح کی ضرورت نہیں — کام بند ہو جاتا ہے، کام کا بوجھ کم ہو جاتا ہے۔ Microsoft Research کے مطابق، ڈویلپر 23% معاملات میں دوبارہ کام سے بچنے کے لیے جان بوجھ کر بگ کی سنگینی کو کم کرتے ہیں۔ جملہ اس کم کرنے کی ایک ہلکی شکل ہے۔

تیسری وجہ کارپوریٹ کلچر ہے۔ کچھ کمپنیوں میں، بگ ڈویلپر کے KPI کو متاثر کرتے ہیں، اور کوڈ ریویو میں بگ ڈھونڈنا مصنف کی غلطی سمجھا جاتا ہے۔ ایسے ماحول میں، جملہ «یہ بگ نہیں، یہ فیچر ہے» کیریئر کے لیے منفی نتائج سے بچنے کا ایک طریقہ ہے۔ صحت مند غلطی کلچر (بے الزام ثقافت) اس وجہ کو ختم کرتا ہے: اگر بگ کی سزا نہ ہو، تو انہیں تسلیم کرنا آسان ہے۔

بگ اور فیچر کے درمیان لکیر کہاں ہے

واضح حد صرف قبولیت کے معیار کی موجودگی میں موجود ہوتی ہے۔ اگر رویہ قبولیت کے معیار کے کسی بھی نقطے سے مطابقت نہیں رکھتا — یہ بگ ہے۔ اگر رویہ قبولیت کے معیار سے مطابقت رکھتا ہے لیکن صارف پسند نہیں کرتا — یہ UX مسئلہ ہے، بگ نہیں۔ اگر قبولیت کا معیار نہیں ہے — کوئی بھی رویہ فیچر قرار دیا جا سکتا ہے، اور یہ جملے کے پائیدار ہونے کی بنیادی وجہ ہے۔

ایک عملی اصول: بگ اس وقت ہوتا ہے جب پروگرام تصریح کے مطابق وہ کام کرے جو اسے نہیں کرنا چاہیے، یا وہ کام نہ کرے جو اسے کرنا چاہیے۔ فیچر اس وقت ہوتا ہے جب پروگرام وہ کرے جس کا ارادہ تھا، چاہے نتیجہ صارف کو حیران کر دے۔ متضاد معاملات: غیر متعین رویہ (زبان نتیجہ متعین نہیں کرتی)، ریس کنڈیشنز (غیر مستقل طور پر ظاہر ہوتی ہیں)، انتہائی قدریں (99% ڈیٹا کے لیے کام کرتی ہیں)۔

واضح کرنے کے لیے، فیصلہ میٹرکس استعمال کریں:

• رویہ تصریح میں بیان کیا گیا ہے اور درست طریقے سے نافذ کیا گیا ہے — فیچر، چاہے آپ پسند نہ کریں
• رویہ بیان کیا گیا ہے لیکن غلط طریقے سے نافذ کیا گیا ہے — بگ، اصلاح درکار ہے
• رویہ بیان نہیں کیا گیا لیکن ضروریات سے منطقی طور پر اخذ ہوتا ہے — غیر دستاویزی فیچر، تصریح میں شامل کرنے کی ضرورت ہے
• رویہ بیان نہیں کیا گیا اور غیر منطقی ہے — بگ، ضروریات کو واضح کرنے کی ضرورت ہے

سب سے خطرناک صورت اس وقت ہوتی ہے جب تصریح موجود نہ ہو، اور ڈویلپر خود فیصلہ کرے کہ فیچر کیا ہے۔ ایسے منصوبوں میں، کسی بھی غلطی کو «فیچر» قرار دیا جا سکتا ہے، جو پوری ٹیم کے لیے کوڈ کو غیر متوقع بنا دیتا ہے۔ ہر کام کے لیے واضح قبولیت کے معیار — معروضی طور پر حد کھینچنے کا واحد طریقہ۔

ٹیم میں تصورات کی تبدیلی کیوں خطرناک ہے

پہلا خطرہ — معیار کا کٹاؤ۔ اگر ہر بگ کو فیچر قرار دیا جا سکتا ہے، تو ٹیم کے پاس معیاری کوڈ لکھنے کا کوئی محرک نہیں ہے۔ غلطیاں ٹھیک ہونا بند ہو جاتی ہیں، تکنیکی قرض بڑھتا ہے، اور صارفین «عجیب رویے» کے عادی ہو جاتے ہیں۔ جلد یا بدیر، کوئی حریف ایسی مصنوع جاری کرتا ہے جو پیش قیاسی طور پر کام کرتی ہے، اور صارفین چلے جاتے ہیں۔

دوسرا خطرہ — ٹیم میں تنازع۔ QA انجینئر کو ایک بگ ملتا ہے، ڈویلپر کہتا ہے «یہ فیچر ہے»۔ معروضی معیار (قبولیت کے معیار) کے بغیر، بحث ذاتی سطح پر چلی جاتی ہے: «تم ٹیسٹنگ بری کرتے ہو» بمقابلہ «تم پروگرامنگ بری کرتے ہو»۔ PractiTest State of Testing 2023 کے مطابق، «بگ بمقابلہ فیچر» تنازعات QA اور ڈویلپرز کے درمیان رگڑ کی تین بڑی وجوہات میں سے ایک ہیں۔

تیسرا خطرہ — قانونی خطرات۔ ریگولیٹڈ صنعتوں (طب، مالیات، ہوا بازی) میں، «بگ» اور «فیچر» کے تصورات کا قانونی وزن ہے۔ اگر طبی سافٹ ویئر میں کسی رویے کو فیچر قرار دیا جائے لیکن وہ غلط خوراک کے حساب کتاب کا باعث بنے — یہ مذاق نہیں، ریگولیٹری تقاضوں کی خلاف ورزی ہے۔ حفاظت کے لیے اہم نظام تصورات کی تبدیلی کو برداشت نہیں کرتے، اس لیے وہ ہمیشہ رسمی تصدیق استعمال کرتے ہیں۔

بگ اور فیچر کے درمیان الجھن کو کیسے روکیں

بنیادی آلہ — ہر کام میں واضح قبولیت کے معیار۔ قبولیت کے معیار ترقی شروع ہونے سے پہلے لکھے جاتے ہیں: «X داخل کرنے پر، سسٹم کو Y نکالنا چاہیے»۔ اگر رویہ بیان نہیں کیا گیا — یہ ڈیفالٹ طور پر بگ ہے، چاہے ڈویلپر دوسری رائے رکھتا ہو۔ قبولیت کے معیار قابل پیمائش اور قابل تصدیق ہونے چاہئیں: «بٹن سبز ہے» برا ہے، «HEX #00FF00» اچھا ہے۔

دوسرا آلہ — ٹیم میں مکمل ہونے کی تعریف۔ «کام مکمل» کے معنی کی واضح وضاحت: کوڈ لکھا گیا، ٹیسٹ لکھے گئے، ٹیسٹ پاس ہوئے، کوڈ ریویو مکمل ہوا، سٹیجنگ پر ڈپلائے کیا گیا، QA کے ذریعے ٹیسٹ کیا گیا۔ اگر مکمل ہونے کی تعریف کے تمام نکات پورے ہو گئے ہوں اور صارف پھر بھی شکایت کرے — یہ بگ نہیں، بلکہ ایک غائب ضرورت ہے جو بیک لاگ میں نئے فیچر کے طور پر جاتی ہے۔

تیسرا آلہ — بے الزام پوسٹ مارٹم ثقافت۔ اگر بگ کو فیچر قرار دے کر پروڈکشن میں بھیج دیا گیا — ہم وجوہات کا تجزیہ کرتے ہیں، قصوروار نہیں ڈھونڈتے۔ ڈویلپر نے کیوں سوچا کہ یہ فیچر ہے؟ QA نے کیوں نظرانداز کیا؟ قبولیت کے معیار نامکمل کیوں تھے؟ ان سوالوں کے جوابات عمل کو بہتر بناتے ہیں، لوگوں کو سزا نہیں دیتے۔ نظامی بہتری جملہ «یہ بگ نہیں، یہ فیچر ہے» پر پابندی لگانے سے زیادہ مؤثر طریقے سے کام کرتی ہے۔