5. Ποτε Ένα Τριαντάφυλλο δεν Είναι Τριαντάφυλλο?

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

Αλλά το πρώτο πράγμα που έκανα ήταν να οργανώσω εκ νέου και να απλοποιήσω πολύ τον popclient. Η υλοποίηση του Carl Harris ήταν πολύ ηχηρή αλλά παρουσίαζε μια μη αναγκαία πολυπλοκότητα, κοινή σε πολλούς προγραμματιστές C. Μεταχειρίστηκε τον κώδικα σαν να είναι το κέντρο και τις δομές δεδομένων σαν υποστήριξη του κώδικα. Με αποτέλεσμα ο κώδικας να είναι όμορφος αλλά οι δομές δεδομένων σχεδιασμένες ad hoc και μάλλον άσχημες (τουλάχιστον σύμφωνα με τα υψηλά στάνταρ αυτού του παλιού LISP hacker).

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

Τον πρώτο μήνα ακολουθούσα την υλοποίηση του βασικού σχεδιασμού του Carl. Η πρώτη σοβαρή αλλαγή που έκανα ήταν να εισάγω υποστήριξη ΙΜΑΡ. Αυτό το έκανα με την εκ νέου οργάνωση των πρωτοκόλλων σ' έναν γενικό driver και σε τρεις πίνακες μεθόδων (για ΡΟΡ2, ΡΟΡ3 και ΙΜΑΡ). Αυτή και η προηγούμενη αλλαγή απεικονίζουν μια γενική αρχή που είναι καλό να έχουν κατά νου οι προγραμματιστές, ιδιαίτερα σε γλώσσες όπως η C που κανονικά δεν διαθέτουν δυναμική δακτυλογράφηση.

9. Έξυπνη δομή δεδομένων και κουτός κώδικας δουλεύουν καλύτερα απ' το αντίστροφο.

Brooks, Κεφάλαιο 9: "Αν μου δείξεις τον κώδικά σου και κρύψεις την δομή των δεδομένων σου, θα παραμείνω σε σύγχυση. Αν μου δείξεις την δομή των δεδομένων σου, δεν θα χρειαστώ τον κώδικά σου. Σύντομα θα τον μάθω".

Στην πραγματικότητα ο Brooks, στην παραπάνω παράγραφο, αναφέρεται σε "διαγράμματα ροής" και "πίνακες". Χρησιμοποιώντας, όμως, τριάντα χρόνων ορολογικής /πολιτιστικής μεταλλαγής, είναι σχεδόν το ίδιο.

Σ' αυτό το σημείο (αρχές Σεπτέμβρη 96, έξι μήνες από την ώρα μηδέν) άρχισα να σκέφτομαι ότι μια αλλαγή ονόματος ίσως είναι επιθυμητή-στο κάτω της γραφής, δεν ήταν πια απλά ένας POP client. Δίστασα, όμως, επειδή τίποτα στον σχεδιασμό δεν ήταν γνήσια καινούριο. Η έκδοση του popclient μου έπρεπε να αποκτήσει δική της ταυτότητα.

Αυτή η κατάσταση άλλαξε ριζικά όταν το fetchmail έμαθε πώς να προωθεί τα παραληφθέντα μηνύματα στην θύρα SMTP. Θα μιλήσω γι' αυτό σε λίγο. Είπα προηγουμένως ότι είχα αποφασίσει να χρησιμοποιήσω αυτό το σχέδιο για να δοκιμάσω την θεωρία μου σχετικά με την συμβολή του Linus Torvalds. Αυτό το έκανα ως εξής:

1. Εξέδιδα νωρίς και συχνά (Τουλάχιστον μια φορά στις δέκα μέρες. Στη διάρκεια περιόδων έντονου προγραμματισμού, κάθε μέρα).
2. Μεγάλωσα την λίστα των δοκιμαστών beta προσθέτοντας σ' αυτή κάθε έναν που επικοινωνούσε μαζί μου για το fetchmail.
3. Έστελνα φιλικές ανακοινώσεις στα μέλη της λίστας μετά από κάθε έκδοση, ενθαρρύνοντας τον κόσμο να πάρει μέρος στο εγχείρημα.
4. άκουγα τους δοκιμαστές μου, σφυγμομετρώντας ανάμεσά τους για τις αποφάσεις του σχεδιασμού, ευχαριστώντας τους κάθε φορά που απαντούσαν κι έστελναν διορθώσεις.

10. Αν φέρεσαι στους δοκιμαστές σου σαν να είναι η πιο πολύτιμη πηγή σου, θα ανταποκριθούν σαν η πιο πολύτιμη πηγή σου.

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

Όπως διαπίστωσα στα τέλη Μαΐου 1997, η λίστα άρχισε να χάνει από τα περίπου 300 μέλη της, που είναι και ο μεγαλύτερος αριθμός τους, για έναν σημαντικό λόγο. Πολλοί άνθρωποι μου ζήτησαν να τους διαγράψω από την λίστα επειδή το fetchmail δούλευε τόσο καλά γι' αυτούς που δεν χρειάζονταν πλέον να είναι στη λίστα! Ίσως, κάτι τέτοιο είναι μέρος του φυσικού κύκλου ζωής κάθε ώριμου σχεδίου που υιοθετεί το στυλ "παζαριού".