Στη μηχανή
Δεν περιορίζεται στο να πει ότι χρειάζεται καταγραφή κραδασμών. Συνδέει τον αισθητήρα, αποθηκεύει τις μετρήσεις, γράφει τον αλγόριθμο και δημιουργεί την πρώτη πραγματική καμπύλη.
Η φυσική αποστολή
Τι προσπαθεί να πετύχει πρώτα ο κάθε ρόλος;
Developer
Να μετατρέψει μια απαίτηση σε λειτουργία
Ο developer παίρνει κάτι ασαφές —«θέλω να καταχωρίζω παραγγελίες»— και το μετατρέπει σε σαφή πεδία, κανόνες, APIs, πίνακες βάσης δεδομένων, permissions και αποτέλεσμα στην οθόνη.
Η επαγγελματική του καθημερινότητα τον εκπαιδεύει να κλείνει κενά λογικής. Ο κώδικας είτε κάνει αυτό που πρέπει είτε δεν το κάνει. Η λειτουργία είτε ολοκληρώνεται είτε επιστρέφει error.
Το default ερώτημα είναι: «Πώς θα το κάνω να δουλέψει σωστά κάθε φορά;»
Engineer / Μηχανικός
Να δημιουργήσει κάτι που θα επιβιώσει εκτός του μυαλού του
Ο engineer δεν παραδίδει το αντικείμενο σε έναν δεύτερο engineer που γνωρίζει όλες τις υποθέσεις του σχεδιασμού. Το παραδίδει σε ανθρώπους που δεν είδαν τα σχέδια, δεν διάβασαν την ανάλυση και δεν γνωρίζουν πού βρίσκεται το όριο.
Ξέρει ότι κάποιος θα το χρησιμοποιήσει ανάποδα, θα ξεχάσει τη συντήρηση, θα υπερφορτώσει τον μηχανισμό, θα αγνοήσει την προειδοποίηση ή θα επιχειρήσει μία χρήση που κανένας λογικός τεχνικός δεν είχε σκοπό να κάνει.
Το default ερώτημα είναι: «Πώς θα αποτύχει όταν βρεθεί στα χέρια της πραγματικότητας;»
Η εικόνα της αποτυχίας
Τι σημαίνει «απέτυχε» μέσα στο μυαλό του;
Developer
Η αποτυχία είναι bug, exception ή μη αναμενόμενο state
Αν η φόρμα δεν αποθηκεύει, αν το API επιστρέφει λάθος response, αν η βάση κλειδώνει ή αν η εφαρμογή πέφτει, υπάρχει ένα τεχνικό πρόβλημα που πρέπει να αναπαραχθεί και να διορθωθεί.
Αυτό δημιουργεί ένα πανίσχυρο mindset συνέπειας. Ο developer μαθαίνει να μην αποδέχεται το «περίπου δουλεύει». Πρέπει να βρει την αιτία, να γράψει τη διόρθωση και να κάνει deploy μία λειτουργική εκδοχή.
Engineer / Μηχανικός
Η αστοχία δεν είναι εξαίρεση. Είναι αναμενόμενο στάδιο της ανάπτυξης
Το πρώτο πρωτότυπο σχεδόν ποτέ δεν είναι το τελικό. Θα λυγίσει, θα υπερθερμανθεί, θα κάνει συντονισμό, θα κουραστεί, θα σπάσει σε σημείο που δεν είχε προβλεφθεί ή θα αποκαλύψει ότι ο άνθρωπος το χρησιμοποιεί διαφορετικά από το σχέδιο.
Ο μηχανικός μπορεί να γνωρίζει από την πρώτη ημέρα ότι θα χρειαστούν επτά ή οκτώ καταστροφές μέχρι να εμφανιστούν οι πραγματικές αδυναμίες. Δεν θεωρεί την καταστροφή προσωπική αποτυχία. Τη θεωρεί δεδομένο μέτρησης.
Τα tests που γνωρίζει καλύτερα
Απέναντι σε ποιον αντίπαλο δοκιμάζει το σύστημα;
Developer
Δοκιμάζει τον κώδικα απέναντι σε τεχνικά σενάρια
Unit tests, integration tests, load tests, regression tests, retries, timeouts, invalid payloads, network failures, concurrent requests και permissions είναι πραγματικά tests αποτυχίας. Δεν είναι καθόλου επιφανειακά.
Συχνά, όμως, έχουν δημιουργηθεί από ανθρώπους που γνωρίζουν ήδη πώς λειτουργεί το σύστημα. Ελέγχουν γνωστές τεχνικές αστοχίες και λογικά edge cases. Ο αντίπαλος παραμένει ένας άλλος τεχνικός νους ή μία προβλέψιμη υποδομή.
Τι θα γίνει αν το API καθυστερήσει πέντε δευτερόλεπτα;
Τι θα γίνει αν δύο requests ενημερώσουν ταυτόχρονα την ίδια εγγραφή;
Τι θα γίνει αν ένα πεδίο είναι κενό ή έχει λάθος τύπο δεδομένων;
Τι θα γίνει αν ο server επανεκκινήσει στη μέση μιας συναλλαγής;
Engineer / Μηχανικός
Δοκιμάζει το σύστημα απέναντι σε χρήση, κατάχρηση και φθορά
Δεν αρκεί να λειτουργεί στις ονομαστικές συνθήκες. Πρέπει να λειτουργεί όταν η θερμοκρασία αλλάξει, όταν ένα εξάρτημα γεράσει, όταν η τροφοδοσία διακοπεί, όταν ο χειριστής πανικοβληθεί ή όταν δύο αστοχίες εμφανιστούν μαζί.
Το test δεν γράφεται μόνο από κάποιον που κατανοεί το σύστημα. Γράφεται και από τη βαρύτητα, την τριβή, την κόπωση, τον χρόνο, το νερό, τη σκόνη, τον βιαστικό χρήστη και τον άνθρωπο που δεν διάβασε ποτέ το manual.
Τι θα γίνει αν το φορτίο είναι διπλάσιο από το αναμενόμενο;
Τι θα γίνει αν ο χρήστης ενεργοποιήσει δύο αντίθετες εντολές μαζί;
Τι θα γίνει αν ο αισθητήρας δώσει απολύτως λογική αλλά λανθασμένη τιμή;
Τι θα γίνει αν η βλάβη εμφανιστεί όταν κανένας τεχνικός δεν είναι διαθέσιμος;
Ο χρήστης στο μυαλό του
Ποιον άνθρωπο φαντάζεται ότι θα χρησιμοποιήσει το αποτέλεσμα;
Developer
Ο χρήστης ακολουθεί τη ροή που σχεδιάστηκε
Ο developer συνήθως βλέπει τον χρήστη μέσα από interfaces, actions και permissions. Ο χρήστης ανοίγει τη φόρμα, συμπληρώνει τα δεδομένα, πατά αποθήκευση και περιμένει το αποτέλεσμα.
Η λογική είναι εύλογη: το προϊόν πρέπει να είναι καθαρό, γρήγορο και κατανοητό. Όμως η πραγματικότητα θα φέρει ανθρώπους χωρίς τεχνικό πλαίσιο, υπό πίεση, με ελλιπή εκπαίδευση, περισπασμούς και προσωπικά κίνητρα.
Engineer / Μηχανικός
Ο χρήστης είναι μη εκπαιδευμένος, βιαστικός και απρόβλεπτος
Αυτό δεν είναι προσβολή προς τον χρήστη. Είναι παραδοχή ότι ο χρήστης δεν έχει τις γνώσεις του δημιουργού και δεν βρίσκεται σε εργαστήριο. Μπορεί να είναι κουρασμένος, φοβισμένος, αφηρημένος, πιεσμένος ή απλώς να παρερμηνεύσει την ένδειξη.
Η σύγχρονη σχεδίαση οφείλει να θεωρεί φυσιολογικό ότι το λογισμικό θα χρησιμοποιηθεί από ανθρώπους χωρίς τεχνική κατάρτιση και χωρίς την κοινή λογική που ο δημιουργός θεωρεί αυτονόητη. Η ασφάλεια δεν μπορεί να εξαρτάται από την ιδανική συμπεριφορά.
Το κουμπί «Ολοκληρώθηκε»
Πότε μία τεχνικά σωστή λειτουργία γίνεται επιχειρησιακά επικίνδυνη;
Developer
Το κουμπί «Ολοκληρώθηκε» λειτουργεί τέλεια
Ο developer υλοποιεί το κουμπί. Ελέγχει το permission, ενημερώνει το status, καταγράφει timestamp και εμφανίζει επιτυχές μήνυμα. Τεχνικά, η λειτουργία είναι άψογη.
Στο μυαλό του, το πάτημα σημαίνει ότι η εργασία ολοκληρώθηκε. Η εφαρμογή εκτελεί σωστά αυτό που της ζητήθηκε. Το σύστημα δουλεύει.
Η λειτουργία είναι σωστή. Η σημασία του πατήματος θεωρείται δεδομένη.
Engineer / Μηχανικός
Το κουμπί «Ολοκληρώθηκε» είναι μία επιχειρησιακή δήλωση
Ο engineer δεν ρωτά μόνο αν το status αλλάζει. Ρωτά αν επιτρέπεται να αλλάξει. Υπάρχει αποδεικτικό; Έχει ολοκληρωθεί το προηγούμενο στάδιο; Υπάρχει φυσική παραλαβή; Ποιος αναλαμβάνει την ευθύνη; Μπορεί ο ίδιος άνθρωπος να δημιουργήσει και να εγκρίνει;
Σχεδιάζει το σύστημα ώστε το κουμπί να παραμένει κλειδωμένο μέχρι να υπάρχουν τα γεγονότα που δικαιολογούν το πάτημα. Αν πατηθεί, η παλιά κατάσταση δεν εξαφανίζεται και η ευθύνη δεν μπορεί να μεταφερθεί αργότερα σε άλλον.
Η λειτουργία δεν αρκεί να δουλεύει. Πρέπει να αρνείται να λειτουργήσει όταν η πραγματικότητα δεν τη στηρίζει.
Η μεγάλη δύναμη
Γιατί το σωστό σύστημα χρειάζεται και τα δύο mindsets;
Developer
Χωρίς αυτό το mindset, τίποτα δεν θα τελείωνε
Η ικανότητα να μετατρέπεις χάος σε λειτουργικό κώδικα είναι θεμελιώδης. Ο developer δημιουργεί εργαλεία, αυτοματισμούς και υποδομές που μπορούν να επαναλαμβάνουν μια διαδικασία εκατομμύρια φορές.
Δεν είναι «λιγότερο» από engineering. Είναι διαφορετική εστίαση. Κάποιος πρέπει να κάνει το σύστημα πραγματικό, να το ολοκληρώσει και να το κρατήσει λειτουργικό.
Engineer / Μηχανικός
Σχεδιάζει την επιβίωση, όχι μόνο τη λειτουργία
Ο engineer δημιουργεί όρια, interlocks, fail-safe states, συντελεστές ασφαλείας, audit trails, φυσικούς περιορισμούς και διαδικασίες που σταματούν την αλυσίδα όταν λείπει μία κρίσιμη προϋπόθεση.
Δεν προσπαθεί να αποδείξει ότι ο χρήστης έκανε λάθος. Προσπαθεί να εμποδίσει το λάθος του χρήστη να μετατραπεί σε καταστροφή.