Πριν από λίγη ώρα ανέβασα ένα θα ήθελα να πιστεύω ενδιαφέρον άρθρο στο Business of Software του περίφημου Joel.
Θα με ενδιέφεραν οι απόψεις σας.

Ευχαριστώ
Δημήτρης Στάικος
Unibrain

ΥΓ: Κάτι παίχτηκε με το link, see below.

---

The fact that the program works is irrelevant.

Μήπως το link έχει πρόβλημα;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Μάλλον κάτι παίχτηκε .
Μπορεί να το σβήσανε επειδή δεν τους άρεσε  ή απλά ο νόμος του Μέρφυ .

Ιδού λοιπόν το post που τίθεται προς σχολιασμό. Ελπίζω αυτό το link να μην έχει πρόβλημα .

Ευχαριστώ,

Δημήτρης Στάικος
Unibrain

---

The fact that the program works is irrelevant.

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

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Πολύ ενδιαφέρον το τελευταίο metric - δεν το είχα συνδιάσει με κάτι σχετικό με την εμπειρία ενός developer.

Δεν νομίζω ότι βάζοντας, και μόνο, τα λεφτά που διακινούνται είναι ένα καλό metric - δεν είναι αναγκαίο μόνο το software που χρησιμοποιούν τραπεζικοί/χρηματιστηριακοί οργανισμοί να κάνει κάποιον experienced developer. Προσωπικά κάποιον που θα μου έλεγε, ότι έχει συμμετάσχει να φτιαχτεί το πρόγραμμα που χρησιμοποιούν ελεκτές εναέριας κυκλοφορίας, θα τον είχα σε μεγαλύτερη υπόληψη, από κάποιον που έφτιαξε software για τράπεζα...

 

George J.

ΥΓ:  40K$ = 40000 Εσκούδα Πορτογαλίας, $40K = 40000 δολλάρια Ηνωμένων Πολιτειών Αμερικής...

---

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

Εγώ θα διαφωνήσω με το LOC (Lines of Code) ως developer metric.

Μπορεί κανείς να γράψει 100 concrete classes που θα έχουν τα ίδια ή παρόμοια attributes και methods ή να γράψει μία abstract και ορισμένα specializations. Στη μία περίπτωση μπορεί να έχεις 10Κ LOC και στην άλλη 1Κ LOC. Ποιός είναι πιό αποτελεσματικός;

---

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

DotSee Web Services

Χμμμ... Βάζουμε τα χεράκια μας να βγάλουμε τα ματάκια μας... Αν αυτά τα metrics τα είχε προτείνει κάποιο Pointy Haired Boss δεν θα μου έκαναν εντύπωση καθώς τέτοιοι άνθρωποι δεν μπορούν να κατανοήσουν (όπερ σημαίνει "μετρήσουν") την πνευματική εργασία ενός developer και καταφεύγουν στα νούμερα προκειμένου να βγάλουν άκρη. Κατ' εμέ, δεν μπορούν να δώσουν τίποτε άλλο πέρα από μια πολύ γενική εικόνα για κάποιον developer, ιδιαίτερα αν χρησιμοποιούνται χωρίς context. Τα προβλήματα αυτής τη συλλογιστικής των metrics που μου έρχονται στο μυαλό είναι διάφορα. Ας πούμε, δεν μπορείς να συγκρίνεις τα metrics ενός developer που γράφει device drivers με κάποιον που γράφει φόρμες. Από την άλλη, τι γίνεται με τον junior που βρίσκει έτοιμο έναν generator (που ίσως έγραψε κάποιος senior) και "παράγει τρία κιλά κώδικα στην καθισιά του"; Τι γίνεται με αυτόν που γράφει 5Κ LOC πάνω στα standard controls της Microsoft για να τα συνεφέρει ώστε να κάνουν αυτά που κάνουν τα controls μιας σουίτας; Τι γίνεται με αυτόν που κάνει copy/paste συνεχώς αντί για code reuse; Η παραγωγή γραμμών κώδικα δεν συνεπάγεται απαραίτητα παραγωγή ποιοτικού κώδικα και κατ’ επέκταση ούτε παραγωγικότητα...

---

Vir prudens non contra ventum mingit

Επιπρόσθετα, η πρακτική εφαρμογή της μεθόδου αυτής είναι λίγο δύσκολη... Αν πήγαινα σε ένα interview και με ρωτούσαν κάτι τέτοιο θα μου ήταν αδύνατο να απαντήσω τι DLOC, τι ILOC και τι DMTS έχω!

---

Vir prudens non contra ventum mingit

Άσε, τα KLOCs τα έχω αντιμετωπίσει αρκετές φορές και τα ... λατρεύω. Θυμάμαι μία φορά που αναγκάστηκα να συνεφέρω μία φόρμα σε C++ η οποία από το πολύ copy-paste είχε φτάσει τις 6000 γραμμές κώδικα, και ο δημιουργός της φοβόταν να τη συμμαζέψει, ενώ για να διορθώσεις ένα λάθος έπρεπε να ψάξεις σε 10 διαφορετικά functions. Μετά από πολύ refactoring, αλλαγή ονομάτων στις ακατάλληπτες μεταβλητές και νέο refactoring, κατέληξε να είναι μόλις 600 γραμμές (νομίζω).

Από την άλλη, χρησιμοποιώντας 2-3 patterns (composite, visitor, strategy, decorator, factory) και μερικές παραμέτρους αποθηκευμένες σε ένα πίνακα, έφτιαξα μία βιβλιοθήκη η οποία διάβαζε γεωγραφική πληροφορία και την εμφάνιζε πάνω σε χάρτι, με annotations και labels. Δεν θυμάμαι πόσες γραμμές ήταν, αλλά πρέπει να ήταν κάπου 1000-2000.

Και το ωραιότερο, χρησιμοποιώντας μία πλατφόρμα στην οποία ορίζεις business entities και workflows, μπορείς να φτιάξεις μεγάλες και περίπλοκες εφαρμογές (με εξαψήφια DMTS) γράφοντας ελάχιστο κώδικα, κυρίως για ειδικούς υπολογισμούς.

Αααα, και το αγαπημένο μου. Να γράφεις κώδικα για επεξεργασία reports αντί να χρησιμοποιείς DTS. Από τη μία εκατοντάδες ή χιλιάδες γραμμές περίπλοκου κώδικα, από την άλλη μερικά queries. Άραγε, τί είναι γρηγορότερο, ασφαλέστερο και ταχύτερο?

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Όπως δια μαγείας εξαφανίστηκε, έτσι δια μαγείας επανεμφανίστηκε στο Business of Software. Να δούμε τι παρατηρήσεις θα πέσουν και εκεί.

Λοιπόν υπάρχουν αρκετά ωραία σχόλια στο DNZ για μια πρώτη απάντηση εκ μέρους μου:

• Τα metrics αυτά δεν είναι για να χρησιμοποιηθούν ανεξάρτητα από το βιογραφικό. Θα μπορούσαν πιθανά να χρησιμοποιηθούν μέσα στο βιογραφικό. Προσωπικά θα το έβρισκα ενδιαφέρον. Pointy hair managers αποκλείεται να κατανοήσουν κάποιο από αυτά πέρα από το WLOC.
  
• Το WLOC είναι μάλλον το λιγότερο σημαντικό, χωρίς να είναι ασήμαντο. Όπως και στα άλλα βασικά με ενδιαφέρει η τάξη μεγέθους. Αν ο κακός προγραμματιστής γράψει φόρμα με 6000 γραμμές ενώ ο καλός την ίδια φόρμα με 1000, η τάξη μεγέθους δεν επηρεάζεται ιδίως αν συνυπολογίσουμε ότι ο καλός θα τελειώσει πιο γρήγορα και θα έχει λιγότερα bugs, άρα θα ασχολείται να γράφει άλλο κώδικα σε άλλη φόρμα ενώ ο σκράπας ταλαιπωρείται ακόμα με την πρώτη φόρμα.
  Αν λοιπόν ρωτήσω κάποιον και μου πει WLOC=50Κ ενώ ένας άλλος WLOC=60Κ, δεν θα μου κάνει διαφορά. Είναι το ίδιο άπειροι. Αν ο δεύτερος μου απαντήσει WLOC=300K τότε είναι πιθανότατα πιο έμπειρος και από τους δύο. Δεν λέω ότι είναι πιο καλός προγραμματιστής απαραίτητα, όμως στο 95% των περιπτώσεων θα είναι καλύτερος λόγω εμπειρίας.
  Έχω δει ανθρώπους που υποτίθεται ήταν έμπειροι, με WLOC περίπου 200Κ, να φτιάχνουν μια κλάση που ονομάζεται CancelDecorator, αυτό που είχαν υλοποιήσει δεν ήταν decorator και αυτό που πραγματικά χρειαζόταν στην πράξη επίσης δεν ήταν ούτε decorator ούτε αυτό που είχαν υλοποιήσει. Και ο άνθρωπος περηφανευόταν ότι ήξερε Design Patterns! Πολλοί έχουν κολλήσει το patternitis virus, αλλά ελάχιστοι πραγματικά κατανοούν τα design patterns και ξέρουν να τα χρησιμοποιήσουν σωστά, γιατί πολύ απλά είναι ένα τρομερά δύσκολο topic και η χρήση τους κάνει τον κώδικα πολύ πολύ πιο δύσκολο στην κατανόηση και στο debugging. Εγώ προσωπικά αν μπορώ να βρω λύση χωρίς pattern τα αποφεύγω (Brute Force approach).
• Ναι, τα περισσότερα από αυτά τα νούμερα ίσως είναι δύσκολο εως αδύνατον να υπολογιστούν ακριβώς, αλλά αυτό δεν έχει σημασία.
  Π.χ. οι ΙΕΕΕ1394 drivers της Unibrain μοιράζονται σε CD μαζί με διάφορα motherboards. Δεν μπορώ να ξέρω πόσοι χρήστες του έχουν όντως εγκαταστήσει και πόσοι κάνουν κάτι με αυτούς κάθε μέρα. Από την άλλη ξέρω ότι υπάρχουν πολλές εφαρμογές που χρησιμοποιούν τους drivers μας σε εργοστάσια (optical inspection) και τρέχουν 24x7 καθώς και εκατοντάδες άλλες εφαρμογές που χρησιμοποιούν το imaging API μας. Μια μετριοπαθής προσέγγιση θα ήταν ότι καθημερινά πρέπει να τραβιούνται τουλάχιστον 1Μ frames με τις κάμερες μας (σε continuous streaming μπορούν να έχουν μέχρι και 30 frames per sec). Αν για κάθε frame που τραβιέται γίνονται exercise περίπου 5.000 γραμμές κώδικά μου, τότε από αυτό και μόνο έχω ELOC=5x10^9. Αντε να πούμε ότι αν έβαζα και τους υπόλοιπους χρήστες αυτό να γινόταν 8x10^9. Κάνει διαφορά; Δεν νομίζω. Άρα με λίγη προσπάθεια μπορεί ο καθένας να βγάλει ένα πιθανά χρήσιμο νούμερο.
• Όσο για το DMTS το έβαλα γιατί οι developers που γράφουν κώδικα που εκτελεί χρηματικές συναλλαγές είναι σαφώς περισσότεροι από αυτούς που κάνουν εξειδικευμένο software όπως games, flight control, industrial control, real-time systems, κλπ. Όπως είπα τα metrics μπορούν να χρησιμοποιηθούν σαν επαύξηση στο βιογραφικό. Αν είχα μπροστά μου κάποιον που έχει γράψει software για εναέρια κυκλοφορία, μάλλον εγώ θα ήμουν αυτός που θα έψαχνε για δουλειά και εκείνος θα ήταν ο interviewer.
• Επιπλέον είχα σκεφτεί και ένα άλλο metric (για έναν ανεξήγητο λόγο σκέφτομαι metrics στα οποία έχω υψηλό σκόρ... ):
  DPW=Documentation Pages Written
  Εγώ πρέπει να είμαι περίπου στο 800-1000. Δεν το έβαλα γιατί είναι πολύ μεροληπτικό. Δεν έχουν βρεθεί όλοι στην "ευτυχή" θέση να πρέπει να γράψουν πολυσέλιδο documentation. Και ξέρω εκ των πραγμάτων ότι πολλοί το απεχθάνονται ή δεν απλά δεν οίναι σε θαίσοι να τω κάννουν, καθός δεν δουλέβοι ο spel tsecker τουσ.
  
• Τέλος ένα εναλλακτικό point of view για αυτά τα metrics είναι το εξής:
  Αν υποθέσουμε ότι έχετε μπροστά σας 3 υποψηφίους τους οποίους τους θεωρείται τεχνικά ισοδύναμους, καλοί χαρακτήρες όλοι τους, γνωρίζουν το domain, έχουν τελειώσει το ίδιο πανεπιστήμιο, έχουν την ίδια ηλικία, έχουν τα ίδια χρόνια προϋπηρεσίας σε ισοδύναμες εταιρίες, ζητάνε τα ίδια λεφτά, είναι όλοι του ίδιου φύλλου, μιλάνε αγγλικά το ίδιο καλά, δεν έχουν εκκρεμείς υποχρεώσεις (π.χ. στρατό), τότε θα σας ήταν πιθανώς χρήσιμα τα metrics, ναι ή όχι;
  

---

The fact that the program works is irrelevant.

BruteForce wrote:

..., είναι όλοι του ίδιου φύλλου, ....

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

BruteForce wrote:

DPW=Documentation Pages Written

Α γειά σου! Αυτό ΕΙΝΑΙ metric και για μένα. Γιατί υποννοεί και άλλα skills (δεν είναι ο hero κλεισμένος στο dark room γράφοντας κώδικα και απαντώντας με "ουγκ" στον κακόμοιρο αναλυτή/project manager/χρήστη που τόλμησε να κάνει μια ερώτηση αλλά έχει συναίσθηση του τι κάνει και για ποιόν το κάνει).

Προσωπικά δεν έχω επιχειρήσει ποτέ να μετρήσω αλλά σε documentation όλων των επιπέδων (από προκαταρκτικές τεχνικές περιγραφές και τεχνικά τμήματα προσφορών ως documentation εφαρμογών) έχω λιώσει αρκετά πληκτρολόγια.

Να βάλουμε λοιπόν και άλλο ένα metric μια και το συζητάμε το οποίο έχει - πιστεύω - νόημα; PoCL - Percentage of Comment Lines (relevant to KLOC). Προσωπικά θεωρώ οτι uncommented code = hard-to-use code. Δεν μιλάμε για comments του στυλ "This is the default constructor" αλλά για ουσιαστικά comments. Εχουν νόημα μόνο στο context που εξετάζεις τα KLOC και φυσικά με αυτονόητα τα ποιοτικά κριτήρια. Ειναι το ίδιο δύσκολο να μετρηθεί ποιοτικά με το KLOC αλλά - και το λέω για να μην παρεξηγηθώ - δουλεύει μόνο στο ίδιο context με αυτό το metric.

 

---

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

DotSee Web Services

Έχω όμως και εγώ κάποια απορρεία πάνω σε αυτό.

Κάποιες εξειδικεύσεις δε μετρούν;

ΠΧ αν κάποιος είναι εξειδικευμένος στο να επιθεωρεί κώδικα για κενά ασφαλείας δε θα μετρήσει;

Αν κάποιος άλλος πχ έχει ειδικευτεί σε σπάνιες πλατφόρμες (όπως AS400) πώς θα αξιολογηθεί;

Τέλος αυτό το LOC...τότε ο COBOLΑΤΖΉς θα πρέπει να θεωρείται ο super star!

---

Powered by openSuSE 11 64-bit Edition

thrylos wrote:

ΠΧ αν κάποιος είναι εξειδικευμένος στο να επιθεωρεί κώδικα για κενά ασφαλείας δε θα μετρήσει;

Καταρχήν κάποιος που επιθεωρεί κώδικα πρέπει να έχει χτυπήσει top σε όλα τα προαναφερθέντα μεγέθη!
Από την άλλη ο Δημήτρης μιλάει για experience metrics για developers, όχι για άλλες ειδικότητες! Δεν θα αξιολήγουμε την ειδικότητα που λες με τα ίδια μεγέθη, ούτε ένα πωλητή ή μια γραμματέα!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

agmarios wrote:

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

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

http://www.dilbert.com/comics/dilbert/archive/dilbert-20061123.html
http://www.dilbert.com/comics/dilbert/archive/dilbert-20061124.html

---

Νατάσα Μανουσοπούλου