Μια που η συζητηση εχει παρει φωτια ας απαντησει και ένας manager. :). Τα τελευταια χρονια λόγω της δουλειάς μου έχω έρθει σε επαφη με μεγάλες ελληνικές εταιρείες οι οποίες και καλά φτιάχνουν λογισμικό για μεγάλες εφαρμογές που όπως λέτε διαχειριζονται χιλιάδες transactions την ημέρα. Σε πολλές περιπτώσεις όταν κανουμε technical evaluation διαπιστώνουμε:

Α) Πίνακες χωρίς primary keys και indexes. Η δικαιολογία που ακούμε από τους "Chief architects" είναι ότι δεν τα βάζουν γιατί τα index τρώνε πολύ χώρο στο δίσκο.

Β) Πίνακες χωρίς Foreign key constraints. Η δικαιολογία είναι ότι τα FK δυσκολεύουν τους developers και τα CRUD operations.

Γ) Πίνακες με primary keys που είναι σύνθετα κλειδιά με 5-6 πεδία. Οι δικαιολογίες εμπεριέχουν συνήθως αναφορές στον Codd και τις περίφημες αρχές του στις αρχές της δεκαετίας του 80.

Δ) Βάσεις με κύκλους. Η δικαιολογία συνήθως όταν η βάση πεθαίνει ειναι ότι φταίει η Microsoft και οι transaction managers.

E) Βασεις που στην αρχή πετάνε και μετά από λιγο καιρό σέρνονται. Οι συνήθεις ύποπτοι είναι το κακό DB design, ελλειψη των σωστων index, αλλα και αρκετες φορές η ύπαρξη καποιου ξεχασμενου trigger το οποίο ξαφνικά παιρνει πιο πολύ ώρα να εκτελεσθει από όσο θα έπρεπε. Φυσικά δεν είναι  όλα τα triggers κακά, κακά είναι οταν τα χρησιμοποιούμε για να καλύψουμε λανθασμένο DB design. (Και η συγκεκριμένη ερώτηση του thisea -χωρίς παρεξήγηση- φωνάζει κακό design.)

Τέλος όσον αφορά τη διαστρωμάτωση των εφαρμογών, είναι γεγονός ότι αν γράψω μια τεραστια "μονολιθική" εφαρμογή, αυτή θα τρέχει πολύ πιο γρήγορα από μία διαστρωματοποιημενη εφαρμογή. Τη διαστρωμάτωση όμως δεν την κάνουμε για να πάνε οι εφαρμογές πιο γρηγορα. Η διαστρωμάτωση γίνεται για να συντηρείται ο κώδικας ευκολοτερα, για να κάνουμε πιο γρήγορα τις αλλαγές, για να μπορούμε να σπάμε την εφαρμογή μας σε διαφορετικά HW layers κλπ κλπ. Μερικά χαμένα ms per transaction δεν είναι τίποτα μπροστά στις χαμένες τριχες μία κεφαλής που προσπαθεί να αλλάξει μία μονολιθική εφαρμογή, μία stored procedure 5 σελίδων, μια web σελίδα όπου html και κώδικας business logic συνθέτουν ένα τεράστιο μακαρόνι κλπ κλπ.

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

Καλό Δεκαπενταύγουστο

---

jsr

Σπεύδω να διαχωρίσω το μήνυμα από την προηγούμενη συζήτηση, μόνο και μόνο στην σπουδαιότητα των ερωτημάτων που απευθύνει που δεν θα πρέπει να χαθούν στο προηγούμενο θέμα...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Δεν μπορώ να διαφωνήσω με τίποτα από αυτά που γράφεις - αποτυπώνεις την πραγματικότητα όπως είναι.

Αν λάβουμε υπόψη, ότι σήμερα architects/managers είναι αυτοί που είναι ηλικιακά μεγαλύτεροι, έχουν μεγαλύτερη εμπειρία, μπορούμε εύκολα να καταλάβουμε ότι αυτοί είναι οι developers που ήταν στην αγορά πριν από 5-10 χρόνια. Αυτόματα διαπιστώνει κάποιος ότι όλες αυτές οι "αρχές" που "παραβιάζονται" από τις σύγχρονες εφαρμογές, είναι κάποια design patterns άλλων εποχών - εποχών που δεν υπήρχαν οι application servers και γενικά η έννοια server είχε τελείως διαφορετική έννοια από ότι σήμερα, δεν υπήρχαν managed περιβάλλοντα ανάπτυξης, καθώς η θεωρία του application tiering και των software design patterns ήταν στην γένεση τους.

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

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

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Τώρα θα ρίζω λάδι στη φωτία (γιορτινά ) και θα ρωτήσω για ποιόν λόγο θα πρέπει ο προγραμματιστής να εξελίσσεται στον ελεύθερο του χρόνο. ενώ όπως προκύπτει από την ροή των δημοσιεύσεων, ούτε θα χρησιμοποιηθεί στην δουλειά του, ούτε θα εκτιμηθεί ούτε θα αμοιφθεί.
Δεν θέλω να είμαι ειρωνικός ζητώ επιχειρήματα, γιατί δεν στέκει η κουβέντα.
 Προσέξτε: με βάση μόνο τα posts του θέματος, έστω και αν είναι, που δεν είναι, εκτός πραγματικότητας ζητάτε κε Καπνία από κάποιον συνάδελφο να εξελιχθεί, ενώ αυτός που τον διοικεί δεν θα καταλάβει καν που εξελίχθηκε.
Μόνος λόγος (πάλι με βάση το τι βλέπω σε αυτή τη σελίδα) είναι να είναι έτοιμος σε 5 χρόνια να αναλάβει;;

Φλυάρισα πάλι,
sorry

---

Εχετε και οι 2 δίκιο σε αυτά που λέτε.

Όμως θά θελα να επισημάνω μερικά πράγματα σε αυτά που είπε ο Γιώργος. Ότι οι σημερινοί architects/managers μάθανε με παλιότερα εργαλεία, τεχνικές και θεωρίες ναι μεν είναι δικαιολογία αλλά μέχρι ενός σημείου. Ο χώρος εξελίσεται όλο και πιο γρήγορα. Νέα εργαλεία, και νέες τεχνικές αναπτύσονται για να μας απαλλάξουν από προβλήματα του παρελθόντος, θα διευκολύνουν το σχεδιασμό και την ανάπτυξη, θα αυξήσουν την αξιοπιστία, την ταχύτητα, την επεκτασιμότητα, και φυσικά την ευκολία στην συντήρηση. Πολλά από τα προβλήματα του παρελθόντος εκμηδενίζονται (πχ παλιά τα indexes μπορεί να ήταν σπατάλη χρόνου. Οι σημερινές τιμές στους δίσκους όμως καθιστούν γελοία αυτή τη δικαιολογία καθώς τα ωφέλη από την ταχύτητα είναι πολύ περισσότερα. Ειδικά όταν η μεγαλύτερη ταχύτητα σημαίνει μεγαλύτερη κερδοφορία).Όλα αυτά απαιτούν τριβή σε όλα τα επίπεδα. Κάθε ρόλος θα πρέπει να ενημερώνεται στο επίπεδο που χρειάζεται ώστε να αξιοποιεί όλες τις δυνατότητες που υπάρχουν. Χωρίς αυτό να σημαίνει πως πρέπει να υοθετούμε απερίσκεπτα οτιδήποτε νέο γιατί είναι treandy. Καλώς η κακώς η τεχνολογία εξελίσεται γρήγορα και αυτό είναι γνωστό σε όλους. Άρα απαιτείται διαρκής εκπαίδευση και τριβή από όλους.  Οπότε οι συνθήκες στις οποίες γαλουχήθηκαν οι σημερινοί architects δεν αποτελεί συγχωροχάρτι για τις "λάθος" αποφάσεις που  πέρνουν. Τότε δεν είχαν resources, τώρα όμως υπάρχουν. Άλλωστε πρώτοι αυτοί πρέπει να κατευθείνουν τους developers για την αναζήτηση/υόθέτηση νέων τεχνικών, καθώς αυτοί είναι υπεύθυνοι για το mentality της ομάδας.

Ναι μέσα στο εργασιακό περιβάλλον ένας developer είναι δύσκολο να δοκιμάσει και να παίξει με νέα πράγματα. Απαιτείται θυσία ελεύθερου χρόνου. Ωστόσο από την άλλη αυτό είναι που θα του προσθέσει added value και θα του δώσει την ευκαιρία να προχωρίσει ένα βήμα παραπάνω. (Αν διαβάζει ο προιστάμενός μου, θέλω μίαμιση ώρα καθημερινά να αφιερώνεται στη μελέτη και στην δοκιμή νέων τεχνικών )

 

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

Δεν ισχυρίστικα την κατάργηση των SP. απλά πολλά πράγματα τις περισσότερες φορές μπορούν να γίνουν ένα επίπεδο παραπάνω, δίνοντας έτσι ευκολία στη διαχείριση του κώδικα στην ,επεκτασιμότητα, στο μελλοντικό integration με άλλα συστήματα, ακόμα και στην απόδοση. Με διάφορες τεχνικές (πχ caching) μπορείς να βελτιώσεις την συνολική ταχύτητα της εφαμοργής. εκμηδενίζοντας έτσι τη διαφορά που μπορεί να προκύψει από την πιθανή μετατόπηση ενός Layer σε ένα παραπάνω επίπεδο.

Το σίγουρο είναι οτι στο χώρο μας τα πάντα ρει

Γιώργο μακάρι να είναι αληθηνές οι προβλέψεις σου.

---

Γιώργος Σακαλής

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

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

---

Γιώργος Σακαλής

besieger:

Τώρα θα ρίζω λάδι στη φωτία (γιορτινά ) και θα ρωτήσω για ποιόν λόγο θα πρέπει ο προγραμματιστής να εξελίσσεται στον ελεύθερο του χρόνο. ενώ όπως προκύπτει από την ροή των δημοσιεύσεων, ούτε θα χρησιμοποιηθεί στην δουλειά του, ούτε θα εκτιμηθεί ούτε θα αμοιφθεί.
Δεν θέλω να είμαι ειρωνικός ζητώ επιχειρήματα, γιατί δεν στέκει η κουβέντα.
 Προσέξτε: με βάση μόνο τα posts του θέματος, έστω και αν είναι, που δεν είναι, εκτός πραγματικότητας ζητάτε κε Καπνία από κάποιον συνάδελφο να εξελιχθεί, ενώ αυτός που τον διοικεί δεν θα καταλάβει καν που εξελίχθηκε.
Μόνος λόγος (πάλι με βάση το τι βλέπω σε αυτή τη σελίδα) είναι να είναι έτοιμος σε 5 χρόνια να αναλάβει;;

Αφού ζητάς την άποψη μου, να την παραθέσω:

• Ένας προγραμματιστής θα πρέπει να εξελίσσεται αν θέλει να παραμείνει στην πραγματικότητα του επαγγέλματός του - οι ρυθμοί που εμφανίζονται καινούργιες τεχνολογίες ή αλλάζουν/εξελίσσονται οι υπάρχουσες, είναι σημαντικά πιο γρήγοροι στο πεδίο του. Μένοντας σύγχρονος στις γνώσεις του, μπορεί να κάνει πιο γρήγορα και συστηματικά την δουλειά του, καταπονώντας τον εαυτό του το λιγότερο δυνατό για την επίτευξη των στόχων που έχει ή του έχουν τεθεί στο εργασιακό του περιβάλλον. Προσωπικά, το κάνω και για να ικανοποιήσω και την ματαιοδοξία μου σαν άνθρωπος, ότι γίνομαι καλύτερος μέρα με την μέρα.
• Η εξέλιξη δεν είναι υποχρεωτική για κανέναν - παρόλα αυτά, η θεωρία της εξέλιξης μέσα στην φύση, ισχύει και στον επαγγελματικό χώρο. Αν ο χρόνος που διατίθεται για εξέλιξη, μέσα στο εργασιακό του περιβάλλον δεν είναι αρκετός, ένας προγραμματιστής δεν θα πρέπει να εγκαταλείψει την επαγγελματική του εξέλιξη. Ένας τρόπος να εξελιχτεί είναι να το κάνει στον προσωπικό του χρόνο. Άλλος τρόπος είναι να αλλάξει εργασιακό περιβάλλον. Δεν είναι πάντα δυνατό, το ένα ή το άλλο - ιδιαίτερα όταν κάποιος έχει οικογενειακές υποχρεώσεις.
• Οι γνώσεις και η εμπειρία που έχει ένας προγραμματιστής είναι το μόνο πράγμα που έχει να διαπραγματευτεί για να καθορίσει το μισθό του. Η διαπραγμάτευση, μπορεί να γίνεται είτε στην εταιρία που δουλεύει, χρόνο με το χρόνο, ή σε μια νέα εταιρεία όταν προσλαμβάνεται.
• Όλα τα άνθη ενός δέντρου δεν γίνονται φρούτα, όλα έχουν όμως τις προϋποθέσεις/δυνατότητες μέχρι κάποιο σημείο της ύπαρξής τους. Αντίστοιχα στους ανθρώπους, μπορεί όλοι να έχουν τις δυνατότητες για να πάρουν αυτές τις θέσεις, αλλά δεν είναι όλοι ικανοί για να γίνουν project managers/architects. Υπάρχει η πιθανότητα να μην έχουν το συνδιασμό γνώσης/εμπειρίας όταν θα φτάσει η στιγμή, οπότε κάποιοι δεν θα τους δώσουν το "χρίσμα", αλλά υπάρχει και η πιθανότητα να μην θέλουν και οι ίδιοι να λάβουν μια τέτοια θέση.
• Δεν νομίζω ότι θα αργήσει να εμφανίζεται το φαινόμενο, που θέσεις project manager/software architect δεν θα καταλαμβάνονται από άτομα που έχουν γνώση/εμπειρία και βρίσκονται αρκετό χρόνο σε μια εταιρεία, αλλά από νέα άτομα, και στην ηλικία και στην εταιρεία, γιατί θα έχουν αποδειγμένες τις θεωρητικές γνώσεις που απαιτούνται από την πανεπιστημιακή τους εκπαίδευση για να πάρουν την θέση. Έχει συμβεί στο παρελθόν – είναι ιστορικά καταγεγραμμένο - σε άλλα επαγγέλματα, αν δεν έχει αρχίσει να συμβαίνει και για τους προγραμματιστές, θα αρχίσει σύντομα – τα patterns της ιστορίας επαναλαμβάνονται.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George J. Capnias:

Δεν νομίζω ότι θα αργήσει να εμφανίζεται το φαινόμενο, που θέσεις project manager/software architect δεν θα καταλαμβάνονται από άτομα που έχουν γνώση/εμπειρία και βρίσκονται αρκετό χρόνο σε μια εταιρεία, αλλά από νέα άτομα, και στην ηλικία και στην εταιρεία, γιατί θα έχουν αποδειγμένες τις θεωρητικές γνώσεις που απαιτούνται από την πανεπιστημιακή τους εκπαίδευση για να πάρουν την θέση. Έχει συμβεί στο παρελθόν – είναι ιστορικά καταγεγραμμένο - σε άλλα επαγγέλματα, αν δεν έχει αρχίσει να συμβαίνει και για τους προγραμματιστές, θα αρχίσει σύντομα – τα patterns της ιστορίας επαναλαμβάνονται.

Γράφοντας από το φορητό μου ένα ζεστό μεσημέρι στο Βασιλάκι του ν.Ηλείας, στα 350μ. υψόμετρο με σύνδεση dialup - μπλιαχ):

Σε όλα όσα λες συμφωνώ, Γιώργο, στο τελευταίο όμως έχω κάποιες επιφυλάξεις. Ναι, είναι ιστορικά αποδεδειγμένο οτι στην πορεία του χρόνου οι αυτοδίδακτοι και οι εμπειροι λόγω προϋπηρεσίας αντικαθίστανται σταδιακά από τους περισσότερο νέους και εκπαιδευμένους επίσημα σε ένα συγκεκριμένο γνωστικό πεδίο, όμως στην Ελλάδα το φαινόμενο αυτό θα πάρει χρόνια για να αρχίσει να φαίνεται. Ο λόγος; Η νέα γενιά επαγγελματιών βρίσκεται ένα "κλικ" πιό μπροστά από την παλιά στην Πληροφορική, αρκετά όμως κλικ μακρυά από το ζητούμενο. Συγκεκριμένα, εδώ στην Ελλάδα ξεκινήσαμε από τους αυτοδίδακτους ερασιτέχνες, περάσαμε στην πολυαγαπημένη γενιά του "είμαι-μαθηματικος-αρα-ξέρω-και-πληροφορική", στην γενιά του "σπουδάζω-κατι-ασχετο-αλλα-γουσταρω-πληροφορική-και-τα-δινω-ολα-εκεί" (από την οποία προέρχομαι και εγώ), στη γενιά του "έκανα το χόμπυ επάγγελμα" (και από εκεί προέρχομαι πάλι εγώ - βρέθηκα ανάμεσα στις δύο γενιές). Για να φτάσουμε στην γενιά του "σπούδασα πληροφορική και είμαι πληροφορικάριος" - με αποδεδειγμένες ικανότητες, όχι απλά θεωρητικές γνώσεις, θεωρώ οτι πρέπει να περάσουν ακόμα 3-4 γενιές (οπου γενιά = 5ετια). Και αυτό γιατί πρέπει πρώτα το τοπίο να "καθαρίσει" από όλους εμάς (εσάς, αυτούς) που θα έχουν καταλάβει τις υψηλόβαθμες θέσεις και θα κινούν τα νήματα χωρίς να προσφέρουν ευκαιρίες στους νέους επαγγελματίες. Ο "καθαρισμός" βρίσκεται αυτή τη στιγμή στο πρώτο στάδιο, με τους "μαθηματικοπληροφορικάριους" (δεν έχω τίποτα με τους μαθηματικούς, απλά μιλώ για αυτούς που απο καθαρή συγκυρία βρέθηκαν στο χώρο της πληροφορικής επειδή όλος ο κόσμος θεωρούσε οτι ΜΟΝΟ αυτοί έχουν τα προσόντα να ασχοληθούν με τον κλάδο), να απέρχονται σιγά σιγά κυρίως λόγω ηλικίας.

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

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

Γνωρίζετε πολλές σχολές που να μαθαίνουν π.χ. στους φοιτητές design patterns ? Ξέρετε πολλούς να διδάσκουν σύγχρονες μεθοδολογίες ανάλυσης, σχεδίασης και ανάπτυξης ? Επεσε πρόσφατα στα χέρια μου το βιβλίο SW engineering που διδάσκεται στο μεταπτυχιακό Πληροφορικής στο Ανοικτο Πανεπιστήμιο. Ελεος πια με το μοντέλο του Καταρράκτη. Κοιτάζοντας και τα υπόλοιπα βιβλία είδα την ίδια ύλη που είχα διδαχτεί σε προπτυχιακό επίπεδο πριν από 15-17 χρόνια.

Δυστυχώς, από όσες συνεντεύξεις έχω πάρει από νέους ανθρώπως, όχι μόνο στερούνται βασικών γνώσεων, αλλά το χειρότερο είναι ότι δεν το έχουν συνειδητοποιήσει. Δεν είναι λίγες οι περιπτώσεις αποφοίτων Μεταπτυχιακού Πληροφορικής, με μηδενική εργασιακή εμπειρία, οι οποίοι με ενα φοβερό τουπε μου ανακοινώνουν ότι στη σχολή τους εμαθαν ότι το development είναι "μπανάλ" και είναι διαθέσιμοι μόνο για θέση project manager :-)

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

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

---

jsr

Όλα όσα αναφέρθηκαν είναι σωστά και δίκαια και ισχύουν....

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

 Η περίφημη γεννιά των ΦυσικοΜαθηματικών "έδρασε" σε πολύ μεγάλο ποσοστό πολύ πριν τη δική μας, όταν τα τμήματα πληροφορικής υπήρχαν μόνο στην Αγγλία και στην USA.
Αλλά πολύ πριν από αυτούς και σε μεγαλύτερο ποσοστό είναι το "ιερατείο" των μηχανικών του πολυτεχνείου! Εκεί να δείτε ασχετοσύνη!!! Μιλώ για τους... τότε...

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

Ξέρετε, αυτοί του Πολυτεχνείου, οι μηχανικοί,  που τα ξέρουνε ΟΛΑ!... (χε χε σας πειράζω λίγο εσας του Πολυτεχνείο.... μην αρπαχτείτε... πάντα υπήρχε μια "κόντρα")
Ποτέ και κανένας manager και αργότερα οταν είμουνα εγω σε τέτοια θέση είχα από πάνω τον .... ιδιοκτήτη (πάλι μηχανκό ... ρε γαμώτο το χει η τύχη μου)... ποτέ λοιπόν δεν με "άφησε" κανείς να εφαρμόσω όπως εγώ νόμιζα και ήθελα την τεχνολογία!!

ΠΑΝΤΑ υπήρχε ένα εμπόδιο: Ο ΠΕΛΑΤΗΣ!!! Χιλιάδες φορές είχα ακούσει τα παρακάτω από Managers/Ιδιοκτήτες:
-Τι τον νοιάζει τον πελάτη αν εμείς έχουμε 3rd normal form normalization....χεστήκαμε!
-Δεν μπορούμε να περιμένουμε να αναλύσετε εσείς το πρόβλημα με UML και μέτα να ξεκινήσετε την ανάπτυξη,... δεν το αντέχει η εταιρία!
-Ο Πελάτης θέλει να βλέπει οθόνες!! Τι μ@@@κίες κάνετε τόσο καιρόooo ρεεεεεε!!!
-Στα Πανεπιστήμια σας μαθαίνουν παπαρο-θεωρίες ενώ στην πράξη ειναι αλλιώς τα πράγματα!! Εσεις θα μας πείτε τώρα? χα χα....
κλπ κλπ

Με την ίδια λογική λοιπόν που εσείς τα βάζεται με τους 40ρηδες αυτής της εποχής, θα μπορούσα εγώ να τα βάλω με τους 40ρηδες της δικάς μου εποχής (πριν 15 χρόνια) κ.ο.κ. και θα έβγαζα από επάνω μου την.... "ρετσινιά".
Αυτό όπως δεν θα οδηγούσε πουθενά... θα φτάναμε να πούμε τελικά οτι για όλα φταίνε οι προγραμματιστές του... Eniac!!

Αναφέρθηκε οτι ο προγραματιστής πρέπει να ενημερώνετε στον ελεύθερο χρόνο του, διότι στην δουλειά του δεν μπορει... Νομίζω οτι αυτό είναι σωστό. Όπως και η σωστή  είναι και η νοοτροπία ειναι αυτή του Sakalis, o οποίος ανέφερε πως την ενημέρωση πρέπει να την κάνει ο προγραμματιστής για τον εαυτό του και όχι για τον προιστάμενο του.
Και η "αναγνώριση" θα έρθει από αυτήν ή την επόμενη δουλειά!!
Πολύ σωστό...!!

Ακριβώς όμως το ίδιο πράγμα ισχύει και για τον manager... και θα έλεγα σε 2πλό και 3πλό βαθμό!!

H ροή της κουβέντας εξελίχθηκε έτσι (τυχαία βέβαια) και φάνηκε μέχρι τώρα οτι τα κατάλοιπα Clipper κ' DBase III ( αχ!!  ) και γενικά η λογική των ISAM και των Flat Databases πέρασε και στην εποχή των RDBMS επειδή κάποιοι μαθηματικο-Managers ήτανε κολλημένοι εκεί!!

Θα μου επιτέψετε να πω, πως αυτό είναι λάθος και αδικεί πολλούς ανθρώπους της γενιάς μου (including me)...
Αυτοί που κολήσανε σε μια τεχνολογία και δεν ήταν σε θέση να καταλάβουν την νέα απλά (για μένα) δεν ειναι Managers... να μην πω τι είναι καλυτερα.
Ποιός σας είπε οτι το "προνόμιο" της ενημέρωσης για την νέα τεχνολογία το έχει μόνο ο προγραμματιστης?
Πρώτα και πιο κύρια το έχει ο manager o οποίος κατά τη γνώμη μου δεν το κάνει τον ελεύθερο χρόνο του ή όταν γυρνάει σπίτι του,... γιατί απλά δεν έχει ελεύθερο χρόνο και πολλές φορές δεν έχει ούτε σπίτι!!! (μεταφορικά βέβαια!)...
Είναι μέρος της δουλειά του και θέλω να πιστεύω και να ελπίζω οτι τα επόμενα χρόνια οι μεγάλες εταιρίες στην Ελλάδα θα απαιτούν και από τον προγραμματιστή να το κάνει αυτό, σαν μέρος της δουλειας του....

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

Δεν φταίνε βέβαια μόνο αυτοί....
Είμαστε μικρή χώρα με πάρα πολύ χαμηλά budjets και μισθούς... Τα στελέχη πληρώνονται καλά αλλά όχι οι... τεχνικοί...
Στο επάγγελμα που διαλέξαμε δεν θα "πεινάσουμε" αλλά ούτε θα πλουτίσουμε... και σχεδόν πάντα θα είμαστε στο παρασκήνιο και πάντα οι φταίχτες για το κακό software...

Για τα αρχικά ερωτήματα του post τώρα που έγιναν από τον φίλο jsr έχω να πω τα εξής, επειδή τα έχω συνατήσει πολλάκις (τσ τσ τσ... άκου "πολλάκις"):
Ορισμένα είναι απαράδεκτα (βλέπε PK και την αιτιολογία τους),
Ορισμένα οφείλονται στην ασχετοσύνη αυτών που τα αναπτύξανε...
Ορισμένα δεν μπορούσαν να γίνουν αλλιώς (βλέπε monolithism) γιατί απλά δεν... έφτανε ο χρόνος.
 
Τώρα για το ... "κακό design" είναι μια ιστορία που μπορούμε να μιλάμε για μέρες και η οποία με ταλαιπωρεί τα τελευταία 7 χρόνια!!
Μην θεωρεισετε οτι δεν έχουμε περάσει 3-tier τεχνολογίες (μεσω COM - κάποτε δεν είχε και κάτι άλλο), από DLLs που έπρεπε να τις κάνεις register με κάθε αλλαγή, ή μέσω application server τον οποίο χρησιμοποιούμε ακόμα αλλά σε πολύ lihght μορφή - για να το πω Μicrosoftika έχουμε έναν πολύ Thin App Server...

Θέλω να αναφέρω μόνο ένα πράγμα...
Όταν η εφαρμογή πρέπει να αλλάζει κάθε μέρα, και τα rules που ισχύουν τώρα,... αύριο μπορεί να είναι μέρος της αλήθειας ή και λάθος εντελώς... τότε πριν ξεκινήσεις να υλοποήσεις κάτι με layers καλύτερα να σκεφτείς και να βάλεις σε πρώτη προτεραιότητα τον τρόπο που θα το συντηρείς...
Για να μην γίνει παρεξήγηση.... δεν αναφέρθηκα ΠΟΤΕ σε μονολιθική εφαρμογή...
Αυτό που ήθελα να τονίσω είναι είτε 2-tier έιτε 3-tier με έναν πολύ thn-app server και το business login σε stored procedures...
Σκεφτείτε το... λίγο.

---

Nothing to declare...

Θα θελα να προσθέσω μερικά στοιχεία σε όσα προαναφερθηκαν.

Όσον αφορά τους Managers, υπάρχει ένα μεγάλο μερίδιο που γαλουχήθηκαν μέσα από τα ερευνητικά έργα.  Επειδή έχω ζήσει αρκετά μέσα στο πανεπιστημιακό χώρο όσον αφορά την εργασία το manageriliki άρχιζε και τελείωνε με την κατάθεση της πρότασης, και φυσικά το reporting. Κανένας σχεδιασμός για το τι θέλουμε να κάνουμε, κανένας σχεδιασμός πως θα το κάνουμε, κανένας σχεδιασμός πως θα το αξιοποιήσουμε μετά αυτό. Απλά γράφαμε ότι πιο trendy διαβάζαμε στο internet το γράφαμε και μετά λέγαμε στους developers πρέπει να γίνει αυτό που περιγράφτηκε. Σε σημείο που έχω δει να προδιαγράφουν Sun μηχάνιμα για Web Server & database Server και να λένε (εσωτερικά) η βάση θα γίνει σε access γιατί δε μας έφτανε το budget να προδιαγραφτεί Oracle (Ναι υπήρχε Postgress και Mysql)

Όταν αυτό άτομο τελειώσει τα μεταπτυχιακά του θα πάει σε εταιρία ως Manager φυσικά και θα κάνει το ίδιο γιατί αυτό έμαθε. Να τον νοιάζει μόνο το χρονοδιαγραμμα, που ο ίδιος εβγαλε, γιατί έτσι βόλευε. Νά έχει κάνει ένα πρόχειρο σχεδιασμό από μια έρευνα που έκανε στο internet την προηγούμενη μέρα πριν γράψει την πρόταση για τον πελάτη. Να χρησιμοποιήσει 2-3 νέες τεχνολογίες/ τεχνικές που διάβασε στο άρθρο "Από manager σε manager!" χωρίς να ξέρει αν και πως τα resources Που έχει μπορούν να το κάνουν. Με αποτέλεσμα να φτιάχνεται κάτι που να μοιάζει με αυτό που υποσχεθήκαμε.

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

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

---

Γιώργος Σακαλής