Όλες οι σύγχρονες συσκευές και προγράμματα που χρησιμοποιούμε, περιλαμβάνουν κάποιον ή κάποιους να γράφουν εκατοντάδες ή και χιλιάδες γραμμές κώδικα. Από τον browser που χρησιμοποιείται για να διαβάσετε αυτές τις γραμμές, μέχρι την εκτόξευση των πυραύλων του Elon Musk. Όμως, τα λάθη στον προγραμματισμό δεν λείπουν, και πολλές φορές μπορεί να κοστίσουν πολλά εκατομμύρια, ή και ανθρώπινες ζωές.

Δείτε τις ενότητες του οδηγού

Προτάσεις συνεργασίας

Διαφημίστε την επιχειρησή σας στο site του PCsteps, ή και στο κανάλι μας στο YouTube.

Επικοινωνία

Γίνε VIP μέλος στο PCSteps

Τα μέλη διαβάζουν όλα μας τα άρθρα χωρίς διαφημίσεις, και έχουν επιπλέον μοναδικά προνόμια.

Συμμετοχή

World of Warcraft

Στα μέσα της περασμένης δεκαετίας, βιώναμε αναμφισβήτητα την εποχή του World Of Warcraft. Πάνω από 12 εκατομμύρια συνδρομητές και ατελείωτες ώρες παιχνιδιού, στο πιο επιτυχημένο MMO-RPG όλων των εποχών.

Παρά την επιτυχία και τον άρτιο σχεδιασμό του, η Blizzard έκανε ένα προγραμματιστικό λάθος το οποίο προκάλεσε πανικό στους παίκτες.

Τον Σεπτέμβριο του 2005, η Blizzard εισήγαγε ένα καινούριο Dungeon στο World of Warcaft, το Zul’ Gurub. Το τελευταίο boss που οι παίκτες έπρεπε να αντιμετωπίσουν ήταν ο Hakkar.

Ο Hakkar είχε ένα ability που λεγόταν “corrupted blood”, το οποίο μόλυνε τον παίκτη που βρισκόταν κοντά στον Hakkar και προκαλούσε damage over time. Ταυτόχρονα, μεταφερόταν σε όποιον πλησίαζε τον μολυσμένο παίκτη.

Η Blizzard δεν είχε προβλέψει όμως για το τι θα γίνει όταν ένας μολυσμένος παίκτης κάνει teleport από το dungeon και έρθει σε επαφή με άλλους παίκτες. Σαν αποτέλεσμα, πολλοί παίκτες μολύνονταν με το corrupted blood, και στη συνέχεια το μετέφεραν σε παίκτες εκτός του Dungeon.

Έτσι, πολλοί χαμηλού level χαρακτήρες άρχισαν να μολύνονται και να πεθαίνουν. Όπως ήταν φυσικό, προκλήθηκε αναστάτωση και εκνευρισμός στους παίκτες του World Of Warcraft.

Οι servers γέμισαν με “πτώματα” χαρακτήρων, και η Blizzard προσπαθούσε να διορθώσει το λάθος της. Οι παίκτες άρχισαν να trollάρουν και να προσπαθούν να μολύνουν επίτηδες τους υπόλοιπους χαρακτήρες.

Τελικά, το συγκεκριμένο glitch διορθώθηκε μετά από 1 εβδομάδα. Μάλιστα, 2 χρόνια μετά, το περιστατικό μελετήθηκε από επιδημιολόγους για να βγουν συμπεράσματα για το πως θα αντιδρούσε ο πραγματικός κόσμος σε μια επιδημία.

Therac-25

Το συγκεκριμένο προγραμματιστικό λάθος είχε τις πιο μακάβριες συνέπειες, μιας και στοίχισε τη ζωή τουλάχιστον έξι ασθενών στον Καναδά. Πήρε το όνομά του από την μηχανή στης οποίας του κώδικα και έγινε το λάθος.

Η Therac-25 ήταν μια μηχανή που εξέπεμπε ακτινοβολία, για τη θεραπεία του καρκίνου. Αντίστοιχα με τη χημειοθεραπεία, χρησιμοποιήθηκε με την ελπίδα ότι θα καταστρέψει περισσότερα καρκινικά απ' ότι υγιή κύτταρα.

Οι δημιουργοί της μηχανής, Atomic Energy of Canada Limited (AECL), είχαν ήδη κυκλοφορήσει άλλες δύο παρόμοιες μηχανές, την Therac-6 και την Therac-20. Παρ’ όλα αυτά, το τρίτο προϊόν τους έμελλε να αποβεί μοιραίο για έξι άτυχους ασθενείς.

Τα ατυχήματα

H Therac-25 κυκλοφόρησε το 1983. Δούλευε για 2 χρόνια χωρίς κάποιο πρόβλημα, και χρησιμοποιήθηκε σε εκατοντάδες ασθενείς. Μέχρι που το 1985, μια γυναίκα δέχτηκε 100 φορές περισσότερη ακτινοβολία από αυτήν που προέβλεπε η θεραπεία της.

Το αποτέλεσμα ήταν να χάσει το αριστερό της στήθος και την λειτουργία του αριστερού της χεριού λόγω της υπερβολικής ακτινοβολίας. Αντί για την προβλεπόμενη δόση των 200 rad ακτινοβολίας, η άτυχη γυναίκα δέχτηκε 10.000 με 20.000 rad.

Ακολούθησαν άλλοι πέντε ασθενείς που έχασαν τη ζωή τους ή τραυματίστηκαν σοβαρά λόγω “καψίματος” από υπερβολική δόση ακτινοβολίας που εξέπεμψε η μηχανή. Τα παραπάνω περιστατικά τελικά οδήγησαν τις αρμόδιες αρχές να ερευνήσουν το θέμα.

Η έρευνα και το μοιραίο λάθος

Αρχικά, η AECL προσπάθησε χωρίς αποτέλεσμα να βρει τι έφταιγε και προκλήθηκαν όλα αυτά τα ατυχήματα. Τελικά, το λάθος το ανακάλυψε ο Fritz Hager, υπεύθυνος του East Texas Cancer Center.

Το πρόβλημα αποδείχτηκε ότι βρισκόταν στον κώδικα του λογισμικού, το οποίο καθόριζε τη δόση ακτινοβολίας που θα εκπέμψει η Therac-25 στον ασθενή. Βρέθηκαν τουλάχιστον 4 bugs στον κώδικα, τα οποία προκαλούσαν την αυξημένη δόση ακτινοβολίας.

Το πιο “σοκαριστικό” ήταν ότι αποδείχθηκε ότι τον κώδικα τον έγραψε μόνο ένα άτομο. Επιπλέον, ήταν ιδιαίτερα κακογραμμένος και χωρίς τα απαραίτητα σχόλια για την κάθε λειτουργία.

Μάλιστα, ο άνθρωπος που ήταν υπεύθυνος για τον κώδικα δεν δούλευε πια στην εταιρία, και κανείς δεν ήξερε που να τον βρει.

Το επακόλουθο

Τελικά, η AECL διόρθωσε το πρόβλημα με κάποια updates και patches. Οι μηνύσεις από τους συγγενείς των θυμάτων λύθηκαν εκτός δικαστηρίου, και η Therac-25 τέθηκε και πάλι σε λειτουργία.

Το συγκεκριμένο περιστατικό, χρησιμοποιείται σαν παράδειγμα προς αποφυγή για το πως ένας κακογραμμένος κώδικας μπορεί να στοιχίσει ανθρώπινες ζωές. Έμεινε στην ιστορία σαν ένα από τα χειρότερα λάθη στον προγραμματισμό.

Η αποτυχημένη εκτόξευση του Mariner 1

Πριν τον Elon Musk και το Falcon Heavy, η NASA ήταν αυτή που έστελνε πυραύλους στο διάστημα.

Το 1962, θα έστελνε το Mariner 1 στην Αφροδίτη. Το όλο project κόστισε 18.5 εκατομμύρια δολάρια, όμως το ταξίδι του Mariner 1, είχε διάρκεια μόλις κάτω των 5 λεπτών.

Η πιο ακριβή παύλα στην ιστορία

Ο κώδικας του λογισμικού, που ήταν υπεύθυνος για την πορεία του Mariner 1, είχε ένα μικρό λάθος. Του έλειπε μία παύλα. Μπορεί να φαίνεται σχετικά ασήμαντο, αλλά ήταν αρκετό για να βγάλει το Mariner 1 τελείως εκτός πορείας.

Το πρόβλημα παρατηρήθηκε λίγο μετά την εκτόξευση, τον Ιούλιο του 1962. Ο πύραυλος, ανταποκρινόταν παράξενα στις εντολές των ανθρώπων της NASA, και έμοιαζε να βρίσκεται τελείως εκτός ελέγχου.

Η NASA, βλέποντας ότι δεν μπορούσε να επαναφέρει το Mariner 1 σε σωστή πορεία, αποφάσισε να τον καταστρέψει για να μην πέσει σε κάποια κατοικημένη περιοχή.

Τι μας έμαθε?

Σίγουρα έμαθε στους προγραμματιστές της NASA, και όχι μόνο, να ελέγχουν στο μέλλον πιο προσεκτικά τον κώδικά τους. Αλλιώς μπορεί να βρεθούν και αυτοί σε κάποια λίστα με τα μεγαλύτερα λάθη στον προγραμματισμό.

Η κατάρρευση του Hartford Civic Center

Ένα από τα πολλά λάθη στον προγραμματισμό, που όμως στοίχισε πάνω από 90 εκατομμύρια δολάρια. Βέβαια, το συγκεκριμένο ποσό δεν είναι τίποτα μπροστά στις χιλιάδες ανθρώπινες ζωές που θα μπορούσαν να έχουν χαθεί.

Το χρονικό

Το Hartford Civic Center ήταν ένα κτίριο στο Hartford του Connecticut στην Αμερική, που φιλοξενούσε αγώνες hockey, μπάσκετ, και διάφορα άλλα events. Είχε χωρητικότητα πάνω από 16.000 θέσεις.

Η κατασκευή του ολοκληρώθηκε το 1972. Αμέσως μετά, άρχισαν να παρατηρούνται διαφορές ανάμεσα στη μακέτα και στο τελικό αποτέλεσμα. Παρ’ όλα αυτά, οι μηχανικοί θεωρούσαν ότι οι αποκλίσεις ήταν φυσιολογικό να υπάρχουν, και πως δεν αποτελούσε πρόβλημα.

Επιπλέον, από φωτογραφίες που είχαν τραβηχτεί κατά την κατασκευή, βρέθηκαν σημεία στην οροφή του κτιρίου τα οποία θα μπορούσαν να δημιουργήσουν προβλήματα. Όμως οι υπεύθυνοι δεν έδειχναν να νοιάζονται.

Το κτίριο λειτουργούσε κανονικά για πέντε χρόνια, μέχρι που το 1978, μερικές ώρες μετά το τέλος του παιχνιδιού της ομάδας μπάσκετ του πανεπιστημίου του Connecticut, η οροφή κατέρρευσε.

Όπως αποδείχθηκε, ο μεγάλος όγκος του χιονιού που είχε συγκεντρωθεί στην οροφή, σε συνδυασμό με τα κατασκευαστικά λάθη, είχαν σαν αποτέλεσμα την κατάρρευσή της. Ευτυχώς δεν υπήρχαν τραυματίες.

Τι πήγε λάθος?

Οι ηλεκτρονικοί υπολογιστές ήταν κάτι καινούριο εκείνη την εποχή, και οι μηχανικοί δεν ήταν ιδιαίτερα εξοικειωμένοι. Επόμενες έρευνες αποκάλυψαν ότι το λάθος βρισκόταν στο λογισμικό που χρησιμοποιήθηκε για τον σχεδιασμό του κτιρίου.

Το συγκεκριμένο λογισμικό δεν έπαιρνε υπόψιν όλες τις απαραίτητες παραμέτρους για την σωστή κατασκευή του κτιρίου. Επιπλέον, σύμφωνα με τις αρχές που ερεύνησαν το θέμα, η οροφή είχε αρχίσει σταδιακά να υποχωρεί από τη στιγμή που τοποθετήθηκε

Το επακόλουθο

Τρία χρόνια μετά, η αρένα ανακαινίστηκε και συνέχισε να λειτουργεί για τα επόμενα 27 χρόνια. Το περιστατικό μας έμαθε, βέβαια, ότι ένα λογισμικό-πρόγραμμα είναι τόσο καλό όσο ο προγραμματιστής που το έφτιαξε.

Y2K

Οι λίγο μεγαλύτεροι σίγουρα θα θυμάστε τον πανικό που είχε δημιουργηθεί στα τέλη της δεκαετίας του 90 γύρω από το συγκεκριμένο bug.

Πριν το 2000, τα περισσότερα λογισμικά είχαν τις χρονολογίες περασμένες στο σύστημά τους σε συντομογραφία με δύο ψηφία.

Τα Χειρότερα Λάθη στον Προγραμματισμό στην Ιστορία

Δηλαδή η χρονιά 1980 εμφανιζόταν σαν 80, το 1990 σαν 90, κ.ο.κ. Βέβαια αυτοί που σχεδίασαν τα λογισμικά, δεν είχαν προβλέψει τι θα γίνει όταν περάσουμε στο 2000. Με το τότε σύστημα, η ημερομηνία θα εμφανιζόταν σαν 00 και θα δημιουργούσε μία σειρά από προβλήματα.

Τι πιστεύαμε ότι θα προκαλέσει

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

Επιπλέον, υπήρχαν κάποιοι που υποστήριζαν ότι ακόμη και αν διορθώναμε το λάθος, δεν θα γλιτώναμε την “καταστροφή”. Η οικονομία θα έμπαινε σε μία μεγάλη περίοδο ύφεσης, παρόμοια με την Ασιατική κρίση του 1997.

Ένα λάθος που διορθώνεται εύκολα, ή μήπως όχι?

Φαινομενικά, το πρόβλημα θα μπορούσε να λυθεί πολύ εύκολα. Αρκούσε ένα καινούριο update ή patch που θα διόρθωνε τον κώδικα. Τα πράγματα όμως ήταν λίγο πιο περίπλοκα.

Για να γίνει κάποιο update, έπρεπε οι εταιρίες να γνωρίζουν αναλυτικά όλα τα υπολογιστικά συστήματα που χρησιμοποιούσαν. Και αν αυτό σήμερα φαίνεται αυτονόητο, πριν 20 χρόνια δεν ήταν.

Σε ορισμένες περιπτώσεις, υπήρχαν και εκατοντάδες διαφορετικοί τρόποι με τους οποίους ορισμένες ημερομηνίες ήταν αποθηκευμένες. Οπότε με ένα μικρό χάος να επικρατεί σε πολλά IT τμήματα εταιριών και οργανισμών, η κατάσταση ήταν κάπως πολύπλοκη.

Το αποτέλεσμα

Τελικά, συνολικά ξοδεύτηκαν πάνω από 300 δισεκατομμύρια δολάρια για να διορθωθεί το συγκεκριμένο bug. Η κρίση αποφεύχθηκε, και η καταστροφή του σύγχρονου τρόπου ζωής δεν ήρθε ποτέ. Έμεινε όμως στην ιστορία σαν ένα από τα πιο διάσημα λάθη στον προγραμματισμό.

Επιπλέον, ήταν μια από τις ελάχιστες φορές που όλος ο κόσμος συνεργάστηκε για να λύσει ένα πρόβλημα και να αποφύγει δυσάρεστες συνέπειες. Και σε αντίθεση με ό,τι γίνεται συνήθως, πάρθηκαν μέτρα για να προλάβουμε το πρόβλημα, και όχι απλά για να λυθεί αφού έχει δημιουργηθεί.

Η κατάρρευση του δικτύου της AT&T

H ΑΤ&Τ, μία εταιρία κινητής τηλεφωνίας στην Αμερική, αντιμετώπισε τον Ιανουάριο του 1990 ένα σοβαρό πρόβλημα με το δίκτυό της.

Το αποτέλεσμα ήταν πάνω από το 50% των συνδρομητών της να μην μπορούν να πραγματοποιήσουν κλήσεις για πάνω από 9 ώρες.

Ένα “break” που κόστισε ακριβά

Το πρόβλημα δημιουργήθηκε μετά από ένα update στο λογισμικό του δικτύου της AT&T. Το λογισμικό ήταν γραμμένο σε γλώσσα C, και σε μία από τις γραμμές του κώδικα υπήρχε λανθασμένα μία εντολή break.

Το break σταματούσε μία λούπα if, και είχε σαν αποτέλεσμα να δημιουργήσει τεράστιο πρόβλημα στο δίκτυο. Βέβαια, η AT&T δεν ήταν αυτή που βγήκε ζημιωμένη από το συγκεκριμένο λάθος.

Το συγκεκριμένο bug δεν φαίνεται εκ πρώτης όψης να δημιούργησε ιδιαίτερα προβλήματα. Κάποιες χαμένες κλήσεις, ή αν το παρομοιάζαμε με τη σημερινή εποχή, μερικά χαμένα μηνύματα, tweets ή snapchat stories.

Εκατοντάδες εταιρίες έχασαν πιθανές πωλήσεις ή κρατήσεις λόγω της έλλειψης επικοινωνίας. Για παράδειγμα, η αεροπορική American Airlines ανέφερε ότι τη συγκεκριμένη μέρα έχασε τα ⅔ των κλήσεών της.

Τι μας έμαθε?

Έμαθε στις εταιρίες λογισμικού την τεράστια σημασία του ελέγχου του κώδικα. Ένα απλό λάθος μπορεί να κοστίσει ακριβά, και να σε βάλει στη λίστα με τα μεγαλύτερα λάθη στον προγραμματισμό στην ιστορία.

Εσείς ποια πιστεύετε ότι είναι τα μεγαλύτερα λάθη στον προγραμματισμό?

Γνωρίζατε για τα λάθη στον προγραμματισμό που αναφέραμε? Πιστεύετε ότι ξεχάσαμε κάποιο? Γράψτε τη γνώμη σας στα σχόλια.