Οι παράλογοι νόμοι του κόσμου του λογισμικού

Αναρωτηθήκατε ποτέ γιατί οι έξυπνοι άνθρωποι, όπως οι προγραμματιστές λογισμικού, ξεφτιλίζουν τόσο συχνά; Υπάρχουν άνθρωποι που το έκαναν. Σε αυτή την ανάρτηση εξετάζουμε ορισμένοι από τους άγραφους νόμους που περιγράφουν τη συμπεριφορά των επαγγελματιών της πληροφορικής.

Ο πρώτος μου υπολογιστής ήταν ένας Commodore 64. Περίπου 30 χιλιάδες RAM ήταν για το σύστημα, το οποίο άφησε 32 χιλιάδες για επεξεργασία κειμένου, παιχνίδια, λογιστική για την οικογενειακή επιχείρηση και σχεδόν οτιδήποτε άλλο κάνω στον υπολογιστή μου 6 GB. τώρα. Αυτό αφήνει το ερώτημα ανοιχτό. Ο τρέχων εξοπλισμός ανταποκρίνεται στις ανάγκες του λογισμικού ή το λογισμικό χρησιμοποιεί περισσότερους πόρους υλικού επειδή είναι διαθέσιμοι;

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

Εδώ είναι οι αιτίες.

Ο νόμος του Zawinski

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

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

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

Η αρχή του Peter εφαρμόστηκε στο λογισμικό

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

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

Αρχή της ελάχιστης έκπληξης

Δημοσιεύτηκε στο IBM Systems Journal το 1984, αυτή η αρχή αναφέρει ότι:

"Εάν ένα απαιτούμενο χαρακτηριστικό προκαλεί μεγάλη έκπληξη, μπορεί να χρειαστεί να επανασχεδιαστεί το χαρακτηριστικό."

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

Κρίμα που ο Shuttleworth δεν το έλαβε υπόψη του όταν κυκλοφόρησε το Unity.

Νόμος της Κυβερνητικής Εντομολογίας

Το πρώτο bug (bug) στην ιστορία των υπολογιστών ήταν πραγματικό. Ένας σκόρος πέταξε σε ένα από τα ρελέ ενός υπολογιστή MARK II προκαλώντας δυσλειτουργία.

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

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

Νόμος του Kernighan

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

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

Ως εκ τούτου, ο νόμος του Kernighan υποστηρίζει ότι:

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

Ο κανόνας 90/90

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

Ο κόσμος των υπολογιστών έχει τις παραλλαγές αυτού του νόμου. Για παράδειγμα, ένας Tom Cargill είπε:

«Το πρώτο 90 τοις εκατό του κώδικα αντιπροσωπεύει το πρώτο 90 τοις εκατό του χρόνου ανάπτυξης. Το υπόλοιπο 10 τοις εκατό του κώδικα αντιστοιχεί στο άλλο 90 τοις εκατό του χρόνου ανάπτυξης».

Δεν ήταν ξεκάθαρο; Ίσως ο νόμος του Hofstadter να βοηθήσει:

«Πάντα παίρνει περισσότερο χρόνο από όσο περιμένεις, ακόμη και λαμβάνοντας υπόψη τον νόμο του Hofstadter».

Υποθέτω ότι οι προγραμματιστές του Ubuntu και του Fedora πρέπει να γνωρίζουν. Ή τουλάχιστον να το θυμάσαι κάθε 6 μήνες.

Νόμος του Μπρουκ

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

"Η προσθήκη εργατικού δυναμικού σε ένα έργο λογισμικού που εκτελείται με καθυστέρηση θα το καθυστερήσει περαιτέρω."

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

Και φυσικά δεν μπορούμε να ξεχάσουμε τον φίλο Πάρκινσον και τη δήλωσή του ότι Δεν έχει σημασία με πόσο κενό χώρο ξεκινάτε. θα χρειάζεσαι πάντα περισσότερα. Αναφερόταν στον χώρο γραφείου, αλλά το ίδιο ισχύει και για τη μνήμη RAM και τον χώρο στο δίσκο.