Δεν είναι bug, είναι feature — ουσία, προέλευση και διαφορές

Τι σημαίνει «Δεν είναι bug, είναι feature»

«Δεν είναι bug, είναι feature» — μια φράση με την οποία ο προγραμματιστής ή ο διαχειριστής υποδεικνύει ότι η απροσδόκητη συμπεριφορά του προγράμματος είναι σκόπιμη, όχι εσφαλμένη. Στην κλασική περίπτωση είναι ένα αστείο: όλοι καταλαβαίνουν ότι η συμπεριφορά είναι εσφαλμένη, αλλά την αποκαλούν «feature» για να εκτονώσουν την ένταση. Ωστόσο, σε πραγματικά έργα, η φράση χρησιμοποιείται και σοβαρά — όταν η συμπεριφορά αντιστοιχεί πραγματικά στις προδιαγραφές αλλά δεν ανταποκρίνεται στις προσδοκίες του χρήστη.

Η διαφορά μεταξύ bug και feature είναι συχνά υποκειμενική. Για τον προγραμματιστή που έγραψε τον κώδικα, μια συγκεκριμένη συμπεριφορά μπορεί να φαίνεται λογική. Για τον χρήστη — απροσδόκητη και εσφαλμένη. Η υποκειμενικότητα της αντίληψης — ο κύριος λόγος που η φράση είναι τόσο ανθεκτική. Επιτρέπει τη μεταφορά της συζήτησης από το επίπεδο «ποιος φταίει» στο επίπεδο «έτσι σχεδιάστηκε». Σύμφωνα με το UX Collective, το 40% των bug που αναφέρονται από χρήστες είναι στην πραγματικότητα προβλήματα UX, όχι σφάλματα κώδικα.

Στις agile ομάδες, η φράση χρησιμοποιείται συχνά ως αμυντικός μηχανισμός κατά τη διάρκεια demo. Ο προγραμματιστής δείχνει μια απροσδόκητη συμπεριφορά, ο product owner συνοφρυώνεται, και ακούγεται το ιερό «δεν είναι bug, είναι feature». Η εμπιστοσύνη στην ομάδα καθορίζει αν η φράση θα εκληφθεί ως αστείο ή ως απόπειρα απόκρυψης προβλήματος. Σε μια υγιή ομάδα, ένα τέτοιο αστείο εκτονώνει την ατμόσφαιρα, σε μια τοξική ομάδα — προκαλεί σύγκρουση.

Ιστορία της εμβληματικής φράσης

Η πρώτη γνωστή χρήση της φράσης καταγράφηκε το 1976 σε ένα από τα δελτία του DECUS (Digital Equipment Corporation User Society). Ένας χρήστης παραπονέθηκε ότι ο επεξεργαστής κειμένου RUNOFF επεξεργαζόταν λανθασμένα τις κενές γραμμές. Η απάντηση του προγραμματιστή: «Δεν είναι bug, είναι feature — έτσι επεξεργάζονται οι παράγραφοι». Από τότε, η φράση έγινε σύμβολο υπεράσπισης του κώδικα όπως είναι, ανεξάρτητα από την πραγματική του ποιότητα.

Στη διάδοση της φράσης συνέβαλε το Jargon File — το λεξικό της αργκό των χάκερ που τη δεκαετία του 1990 αποτέλεσε τη βάση του βιβλίου «The New Hacker's Dictionary». Στο Jargon File, το λήμμα «feature» αναφέρεται άμεσα σε bug που έγιναν feature λόγω αδυναμίας ή απροθυμίας επιδιόρθωσης. Παράδειγμα: το πλήκτρο Caps Lock στα πρώτα τερματικά δεν είχε ένδειξη — ήταν ένα bug που έγινε feature «για τυφλή πληκτρολόγηση».

Τη δεκαετία του 2000, η φράση πέρασε στη μαζική κουλτούρα μέσω διαδικτυακών meme. Μια εικόνα γάτας με τη λεζάντα «It's not a bug, it's a feature» διαδόθηκε σε φόρουμ και κοινωνικά δίκτυα. Στη βιομηχανία παιχνιδιών, η φράση χρησιμοποιείται ιδιαίτερα συχνά: glitch που δεν επηρεάζουν το gameplay κηρύσσονται «features» για την ατμόσφαιρα. Το πολιτιστικό φαινόμενο έχει ξεπεράσει κατά πολύ την IT — η φράση μπορεί να ακουστεί σε οποιοδήποτε πλαίσιο όπου δικαιολογείται ένα σφάλμα.

Ψυχολογία της δικαιολογίας: γιατί το λένε

Η ψυχολογική βάση της φράσης είναι η γνωστική ασυμφωνία. Ο προγραμματιστής έχει ξοδέψει ώρες γράφοντας κώδικα και το να αναγνωρίσει ότι το αποτέλεσμα είναι εσφαλμένο σημαίνει υποτίμηση της δουλειάς του. Η φράση «δεν είναι bug, είναι feature» μειώνει την ασυμφωνία: το σφάλμα μετατρέπεται σε σκόπιμη απόφαση και ο προγραμματιστής — από ένοχος σε δημιουργό της ιδέας. Αυτός είναι ένας αμυντικός μηχανισμός του ψυχισμού που διατηρεί την αυτοεκτίμηση.

Ο δεύτερος λόγος — φόβος για επαναληπτική εργασία. Αν αναγνωριστεί το bug, πρέπει να περάσει ξανά από code review, δοκιμές και deploy. Το «feature» δεν απαιτεί διόρθωση — η εργασία κλείνει, το φορτίο μειώνεται. Σύμφωνα με τη Microsoft Research, οι προγραμματιστές μειώνουν συνειδητά τη σοβαρότητα των bug για να αποφύγουν επαναληπτική εργασία στο 23% των περιπτώσεων. Η φράση είναι μια ήπια μορφή τέτοιας υποβάθμισης.

Ο τρίτος λόγος — εταιρική κουλτούρα. Σε ορισμένες εταιρείες, τα bug υπολογίζονται στα KPI του προγραμματιστή και η ανακάλυψη bug σε code review θεωρείται σφάλμα του συγγραφέα. Σε τέτοιο περιβάλλον, η φράση «δεν είναι bug, είναι feature» είναι ένας τρόπος αποφυγής αρνητικών συνεπειών για την καριέρα. Η υγιής κουλτούρα σφαλμάτων (blameless culture) εξαλείφει αυτόν τον λόγο: αν τα bug δεν τιμωρούνται, είναι πιο εύκολο να αναγνωριστούν.

Πού βρίσκεται το όριο μεταξύ bug και feature

Σαφές όριο υπάρχει μόνο με την ύπαρξη Acceptance Criteria (κριτηρίων αποδοχής). Αν η συμπεριφορά δεν αντιστοιχεί σε κανένα σημείο του AC — είναι bug. Αν η συμπεριφορά αντιστοιχεί στο AC αλλά δεν αρέσει στον χρήστη — είναι πρόβλημα UX, όχι bug. Αν δεν υπάρχει AC — οποιαδήποτε συμπεριφορά μπορεί να κηρυχθεί feature, και αυτός είναι ο κύριος λόγος ανθεκτικότητας της φράσης.

Πρακτικός κανόνας: bug — όταν το πρόγραμμα κάνει αυτό που δεν πρέπει ή δεν κάνει αυτό που πρέπει σύμφωνα με τις προδιαγραφές. Feature — όταν το πρόγραμμα κάνει αυτό που σχεδιάστηκε, ακόμα κι αν το αποτέλεσμα εκπλήσσει τον χρήστη. Αμφιλεγόμενες περιπτώσεις: undefined behavior (η γλώσσα δεν ορίζει το αποτέλεσμα), race conditions (εκδηλώνονται ασταθώς), ακραίες τιμές (λειτουργεί για το 99% των δεδομένων).

Για τη διάκριση, χρησιμοποιήστε τον πίνακα αποφάσεων:

• Η συμπεριφορά περιγράφεται στις προδιαγραφές και υλοποιείται σωστά — feature, ακόμα κι αν δεν σας αρέσει
• Η συμπεριφορά περιγράφεται αλλά υλοποιείται λανθασμένα — bug, απαιτεί διόρθωση
• Η συμπεριφορά δεν περιγράφεται αλλά προκύπτει λογικά από τις απαιτήσεις — feature χωρίς τεκμηρίωση, πρέπει να προστεθεί στις προδιαγραφές
• Η συμπεριφορά δεν περιγράφεται και είναι παράλογη — bug, απαιτεί διευκρίνιση απαιτήσεων

Η πιο επικίνδυνη περίπτωση — όταν δεν υπάρχουν προδιαγραφές και ο προγραμματιστής αποφασίζει μόνος του τι είναι feature. Σε τέτοια έργα, οποιοδήποτε σφάλμα μπορεί να κηρυχθεί «feature», καθιστώντας τον κώδικα απρόβλεπτο για ολόκληρη την ομάδα. Σαφή Acceptance Criteria για κάθε εργασία — ο μόνος τρόπος να χαραχθεί το όριο αντικειμενικά.

Γιατί είναι επικίνδυνη η υποκατάσταση εννοιών στην ομάδα

Ο πρώτος κίνδυνος — θόλωμα της ποιότητας. Αν κάθε bug μπορεί να κηρυχθεί feature, η ομάδα δεν έχει κίνητρο να γράφει ποιοτικό κώδικα. Τα σφάλματα δεν διορθώνονται, το τεχνικό χρέος αυξάνεται και οι χρήστες συνηθίζουν στην «περίεργη συμπεριφορά». Αργά ή γρήγορα, ο ανταγωνιστής κυκλοφορεί ένα προβλέψιμο προϊόν και οι χρήστες φεύγουν.

Ο δεύτερος κίνδυνος — συγκρούσεις στην ομάδα. Ο μηχανικός QA βρίσκει ένα bug, ο προγραμματιστής λέει «είναι feature». Αν δεν υπάρχουν αντικειμενικά κριτήρια (Acceptance Criteria), η διαφωνία περνά σε προσωπικό επίπεδο: «εσύ κάνεις κακές δοκιμές» vs «εσύ προγραμματίζεις άσχημα». Σύμφωνα με το PractiTest State of Testing 2023, οι διαφωνίες «bug vs feature» είναι μία από τις τρεις κύριες αιτίες τριβής μεταξύ QA και προγραμματιστών.

Ο τρίτος κίνδυνος — νομικοί κίνδυνοι. Σε ρυθμιζόμενες βιομηχανίες (ιατρική, χρηματοοικονομικά, αεροπορία) οι έννοιες «bug» και «feature» έχουν νομική βαρύτητα. Αν σε ιατρικό λογισμικό μια συμπεριφορά κηρυχθεί feature αλλά οδηγεί σε λανθασμένο υπολογισμό δοσολογίας — αυτό δεν είναι αστείο, αλλά παραβίαση κανονιστικών απαιτήσεων. Τα safety-critical συστήματα δεν συγχωρούν την υποκατάσταση εννοιών, γι' αυτό πάντα εφαρμόζουν formal verification.

Πώς να αποτρέψετε τη σύγχυση μεταξύ bug και feature

Το κύριο εργαλείο — σαφή Acceptance Criteria (AC) σε κάθε εργασία. Τα AC γράφονται πριν από την έναρξη της ανάπτυξης: «Με την είσοδο X, το σύστημα πρέπει να δώσει Y». Αν η συμπεριφορά δεν περιγράφεται — είναι bug εξ ορισμού, ακόμα κι αν ο προγραμματιστής πιστεύει διαφορετικά. Τα AC πρέπει να είναι μετρήσιμα και επαληθεύσιμα: «το κουμπί είναι πράσινο» — κακό, «HEX #00FF00» — καλό.

Το δεύτερο εργαλείο — Definition of Done στην ομάδα. Σαφής περιγραφή του τι σημαίνει «η εργασία ολοκληρώθηκε»: κώδικας γραμμένος, δοκιμές γραμμένες, δοκιμές περνούν, code review ολοκληρώθηκε, deploy σε staging, δοκιμασμένο από QA. Αν όλα τα σημεία του DoD εκπληρώνονται αλλά ο χρήστης παραπονιέται — δεν είναι bug, αλλά missed requirement που πηγαίνει στο backlog ως νέο feature.

Το τρίτο εργαλείο — κουλτούρα blameless post-mortem. Αν ένα bug κηρύχθηκε feature και πήγε σε παραγωγή — αναλύουμε τις αιτίες, δεν ψάχνουμε τον ένοχο. Γιατί ο προγραμματιστής αποφάσισε ότι ήταν feature; Γιατί το παρέβλεψε το QA; Γιατί ήταν ελλιπή τα AC; Οι απαντήσεις σε αυτές τις ερωτήσεις βελτιώνουν τη διαδικασία, δεν τιμωρούν ανθρώπους. Οι συστημικές βελτιώσεις λειτουργούν πιο αποτελεσματικά από την απαγόρευση της φράσης «δεν είναι bug, είναι feature».