Real World Operations Research: The Woolsey Papers

Στο μυαλό μου για πολλά χρόνια ο όρος Επιχειρισιακή Έρευνα ήταν συνδεδεμένος με (τραυματικά) iterations του Simplex (με το χέρι). Σε αυτό προσθέστε και το είδος των συμβούλων που έρχονται από το πουθενά, λύνουν ένα πρόβλημα διαφορετικό από αυτό που έχει ο πελάτης (και πληρώνονται ακριβά για αυτό) και αφήνουν πίσω τους συντρίμια κόσμο να κάνει την πραγματική δουλειά (the devil is in the details). Έτσι όταν έπεσα πάνω σε αυτό το post κατάλαβα πως ο Gene Woolsey πρέπει να είναι διαφορετικός. Ψάχνοντας να δω τι έχει γράψει, βρήκα το “Real World Operations Research: The Woolsey Papers“. Είναι μια συλλογή των γραπτών του που καλύπτει μια τριακονταετία.

Δεν με απογοήτευσε. Και πως θα μπορούσε άλλωστε όταν πρόκειται για έναν άνθρωπο που σε keynote speech υπόσχεται στους υπόλοιπους ομιλητές:

I assure you that I will attend every session of this conference, and I plan to ask each speaker these questions:

1. Did you know what they were doing before you modeled it?
2. If yes, how did you know?

If should you be so fortunate as to get by these two questions, I will then move on to ask:

3. Is your model presently in use?
4. If yes, how do you know? (Guess what the acceptable answer is here!)

If you are still alive, I will move on to the grand finale, which is:

5. Does it work?
6. If yes, is there a measurable, verifiable reduction in cost over what was done before, or a measurable, verifiable increase in readiness?
7. If yes, show it to me NOW.

Ο άνθρωπος δεν μασάει τα λόγια του. Ηδη από τις πρώτες σελίδες γράφει “shut up and listen”. Θεωρεί αδιανόητο να προτείνεις βελτιώσεις για την δουλειά κάποιου, χωρίς καν να ξέρεις πως δουλεύει. Κάνοντας τη δουλειά μαζί με το προσωπικό πριν προταθεί λύση, αυξάνεται το PIT factor εκεί που έχει σημασία. Η πιο σημαντική ίσως παρατήρηση που διατρέχει όλες τις σελίδες του βιβλίου είναι πως ο σύμβουλος πρέπει να αντιλλαβάνεται το organizational politics. Γιατί δεν έχει καμία σημασία εάν έχει καταφέρει να σχεδιάσει την καλύτερη δυνατή λύση, εάν αυτή δεν μπορεί να γίνει αποδεκτή για λόγους εσωτερικής πολιτικής. Με λίγα λόγια δηλαδή:

Δεν υπάρχουν τεχνικά προβλήματα, παρά μόνο πολιτικά.

Είναι σημαντικό να καταλάβει κανείς πόσο κοντινά πεδία είναι η συμβουλευτική που ασκούν οι IT και οι OR consultants. Για παράδειγμα και επειδή και οι δύο κατηγορίες καταθέτουν προτάσεις για “νέα, καλύτερα συστήματα” και στις δύο περιπτώσεις ισχύει πως:

If the costs of building a system are greater than the amount it will save you, don’t do it.

Είναι εντυπωσιακό πως υπάρχουν patterns συμπεριφορών που νομίζει κανείς πως “αλλού” δεν εμφανίζονται:

The one thing government seldom gets is honest advice from consultants. Let’s face it, many consultants will say anything they have to in order to be called back.

Κι εγώ που νόμιζα πως αυτό το είδος συμβούλων ταλαιπωρεί μόνο το Ελληνικό Δημόσιο…

Υπάρχει όμως και ένα άλλο είδος συμβούλων. Αυτοί που παρασύρονται από την ικανότητά τους και νομίζουν πως ακριβώς επειδή είναι καλοί, η δουλειά τους “πουλάει” από μόνη της. Ο Woolsey αποκαλεί αυτή την αντίλληψη “professional myopia”: Οι σύμβουλοι υπάρχουν για να λύνουν τα προβλήματα των πελατών τους, όχι για να λύνουν προβλήματα που τους αρέσουν και όταν εμφανιστεί ο πελάτης, να τον προσαρμόσουν στις λύσεις αυτές.

Για χρόνια μου διέφευγε, αλλά είναι μια σωστή τακτική που προτείνει, το να παρουσιάζεις στον πελάτη σου (είτε internal, είτε external consulting) περισσότερες από μία εναλλακτικές λύσεις. Αυτό έχει το ψυχολογικό πλεονέκτημα να μην απορρίψει ο πελάτης τη μία λύση που του παρουσιάζεις. Business is business, αλλά όταν η μία και μοναδική λύση που έχεις σχεδιάσει απορρίπτεται (για οποιοδήποτε λόγο), τότε το παίρνει κανείς και λίγο προσωπικά. Στην περίπτωση των πολλαπλών επιλογών, αυτό συμβαίνει δυσκολότερα και δείχνει πως δεν υπάρχει μόνο ένα course of action.

Δίνει ακόμα και συμβουλές για personal career advancement:

As long as technology is your thing plan to die reading manuals.

Το εντυπωσιακό είναι πως με τις συμβουλές του Woolsey η αλλαγή από το παραπάνω καθεστώς για όποιον την επιθυμεί δεν κοστίζει πάνω από $20. Η γυναίκα μου μου λέει πως το ίδιο έχει πει και ο Χατζηδάκις με άλλα λόγια: “Αν δεν κοιτάς εκεί που θέλεις να πας, θα πας εκεί που κοιτάς”. Πράγματι: Έχω ένα φίλο που 10 χρόνια πριν μου είχε πει “Εγώ φίλε Γιώργο δε θέλω να μείνω τεχνικός, θέλω να διοικήσω”. Είναι γεγονός πως το κατάφερε, όχι μόνο γιατί το ήθελε, αλλά γιατί σκέφτηκε και πως να το πετύχει κιόλας.

Κλείνω με δύο συμβουλές που o Woolsey δίνει προς το τέλος του βιβλίου: Εάν θέλεις να βγάλεις καλά λεφτά και γρήγορα γίνε υδραυλικός. Σύντομα θα οδηγείς Mercedes, θα έχεις το δικό σου ωράριο και πελάτες που θα σε παρακαλάνε. Η δεύτερη και πιο σημαντική:

The trick in life is to find out what you think is play that the fools think is work so that they will pay you to do it.

Μπορείτε να διαβάσετε τη γνώμη και του greenOR για το βιβλίο σε αυτή τη σειρά των τριών post: [1], [2] και [3].

re: 8 Things I Hate About The Web

Boris Veldhuijzen van Zanten writes about 8 things he hates about the web. I tried commenting under his post, but failed (which is somewhat common when replying using OpenID) so here are my comments:

Boris’ points:

  1. Too Cheap. He asks “How much longer will it take until we will have a healthy online economy for start-ups?”. Well, Geoff Huston answered this in one of his brilliant presentations in RIPE-54. In his own words: “You people are cheap! No matter what scientists and engineers do your users will always be looking for the cheapest provider”. This was said while explaining the implications of an earthquake in southeast Asia on the Pacific cables and the Internet connectivity.
  2. Too Many Bugs. I am reading “The New School of Information Security” these days. In its pages it is clearly explained that today, security is not a priority when building a product. And yes, although this covers a fraction of the bugs, getting the product out seems more important than getting the product out bugless. The first part of the “Unifinished Revolution” deals with the subject in depth. Boris asks: “How hard is it exactly to build a browser that works?” You cannot begin to imagine.
  3. Too Many Choices. While I am not a friend of too many choices either, given enough time, the fittest choices will survive. I understand that the problem exists when you are at the start of the timeline, when all choices seem viable (or equally crappy). No we cannot do something about it.
  4. Too Many Browsers. IMHO, this is equal to Too Many Choices (the choice being the browser to use). Standardization is an issue, but we all know that incompatibility with standards occurs when certain groups want to impose their options as default standards for others. When critical mass is gathered, they become de-facto standards. You cannot really hate the web for that. It is a common human / corporate behavior and it is expected.
  5. Too Many Search Results. Well, I believe that one can develop systems that return few and important results as Boris wants. The drawback is that you have to feed such systems with so many details on what is important to you, that in the end you might not like it.
  6. Too Many Opinions. Boris writes: “Opinions are just like assholes, everybody’s got one. On the web, we can all show ours to everyone.” I cannot really comment on that, can I?
  7. Too Slow. The Internet (and not just the Web) will always be too slow. We will always want better speeds and bigger capacities, because there will always be this new thingy that will require the bandwidth. 10 years ago a 1Mbps line was considered enough for a University and today it is considered too slow for my house.
  8. Too Many Passwords. Boris asks about OpenID: “Why the hell isn’t it implemented everywhere yet?” Because as it is pointed out in “The New School of Information Security“, everyone expects everybody else to deploy it before deploying it themselves. So generating the critical mass that will make OpenID commonplace will take time, regardless of the recognized need to use such schemes.

Boris, I think that what you hate is certain human and corporate behavior as it is projected on the web, and not the web itself. For as with most problems, the technical part of the solution is the easy one, while the social and economic parts are the most difficult to get accepted.

(In-Reply-To:)

Ασφάλεια

Απόσπασμα διαλόγου στον οποίο ήμουν ωτακουστής:

– Τι σε πειράζει αν πάθουν κάτι τα μηχανήματα; Αφού είναι ασφαλισμένα και θα πάρεις καινούργια!

Κάποιοι πρέπει να μάθουν να διακρίνουν τις ένοιες safety, security και insurance.

HFrom: $>ruleset and some sendmail ranting

Due to a spam burst last night, I was forced to write a ruleset in the spirit of my previous post:

LOCAL_CONFIG:
HFrom: $>BlockFrom

LOCAL_RULESETS
R$* "NEWS Sensation" $*        $#discard $: discard
R$*        $#OK

Again since this is going straight into your .mc file, it is not advised to use this method frequently. Nice five-liner to stop a spam burst, right?

No! As I was applying this filter I thought that although most people think that sendmail‘s most serious trouble is its bug / security track record, its most serious problem is that decision rules on routing and filtering messages come from all over the place: text files like mailertable, virtusertable, genericstable, relay-domains, access, the sendmail.cf rulesets themselves like the example above and more importantly the milters, their defaults and their configuration files (if any).

Say for example that you do not want email directed to abuse@ to be filtered at all. Depending on your rules and how they are written, you may have to upgrade your rulesets, edit access and probably write an exception for every single milter that you are applying. One exception might need to be declared in five different places. Talk about complication and management nightmare! That is why I like running MIMEDefang: It gives me a Perl interpreter and the ability to implement most of the functionality of any other milter I wish to apply. Have I reached that point of being able to run only one milter? No, but I have set this as a goal. MIMEDefang is not my only choice to this path, j-chkmail seems like a good alternative.

However, I am not the only one who manages our global filters, and I want to make it easier for the other admins to add their own global filters in my absence. Oh how much easier it could have been if the libmilter API offered as a return value a variant of SMFIS_ACCEPT that would instruct sendmail to accept the message with no more milters applied to it. Currently SMFIS_ACCEPT instructs the current milter to accept the message. Which is why if you want to write a global whitelist exception, you may have to write it for all milters that are enabled.

Oh well, I think all I want and wish for is to minimize the number of files I have to edit in order to implement a certain policy (or have a tool that can read the policy from one place and edit n-files for me) and a change to the libmilter API (which I do not know whether it is trivial or not). Suggestions to switch to alternatives like Postfix, Qmail or even Exim are outside the scope of this rant. I prefer to take the “Sendmail Theory and Practice” route and write the whole .mc file by hand instead.

HSubject: and rulesets

This is a variation of the bat book‘s subject header checking trick. Assuming that you want to block messages based on the content of the Subject: header of an incoming message, you can place the following rules into your .mc file:

LOCAL_CONFIG
HSubject: $>BlockSubject

The above basically instructs sendmail to call ruleset BlockSubject with the value of the subject. On with the ruleset now:

LOCAL_RULESETS
SBlockSubject
# The next rule is broken in two for readability!
R$* test - block this message $*
        $#error $: "553 message blocked due to Subject: " $&{currHeader}
R$* Your new password $*        $#discard $: discard
R$* Casinoo $*        $#discard $: discard
R$*        $#OK

(You may want to change the $> operator with $>+. Read paragraph 25.5.1 of the fourth edition of the bat book for a discussion on the matter.)

The bat book prefers to put all the unacceptable subjects in an external database file (which is maintained much like aliases and virtusertable). I prefer keeping the list of the unacceptable subjects inside the .mc file for two reasons:

First, keeping them in a file outside the .mc makes the list grow faster. Editing the .mc to add yet another unacceptable subject makes one think whether to do so or not.

Second, although a subject that contains a certain phrase may be considered unacceptable, you might want to make an exception. For example one may decide to block all the Your new password messages except ISP name – Your new password message that your MIS sends to your users when they reset their password. This can easily be maintained in one place in the .mc file and is also self documented modem noise code:

R$* ISP - Your new password $*        $#OK
R$* Your new password $*        $#discard $: discard

Remember, do not copy-paste sendmail.mc code. The LHS and the RHS are tab separated. Copy-pasting converts tabs to spaces and your ruleset will not work.

on problem solving

(ή πως το γρήγορο hardware μας κάνει τεμπέληδες)

Διαβάζω στο Punk Rock Operations Research:

“Sometimes we rely on software too much and on good modeling too little. A IIE blog entry writes about blindly using software as a quick fix. When computing power wasn’t very powerful, making a tight, efficient formulation was necessary for finding optimal solutions.”

Πόσο αληθινό είναι αυτό. Πάει αργά η εφαρμογή;

– Φταίει ο server. Να πάρουμε καινούργιο για να πάει πιο γρήγορα.

Ενώ στην πραγματικότητα αυτό που φταίει είναι η ίδια η εφαρμογή η οποία δεν μπορεί να εκμεταλλευτεί ικανοποιητικά το υπάρχον hardware και άρα ούτε και το επόμενο. Το να προσθέτεις hardware στη λύση δεν μπορεί να είναι το πρώτο μέτρο- κυρίως γιατί είναι ημίμετρο. Είναι το τελευταίο χαρτί που μπορούμε να τραβήξουμε, όταν δεν μπορούμε να κάνουμε κάτι καλύτερο. Ακόμα θυμάμαι τη συμβουλή εταιρίας να αγοράσουμε το Zend για να “πάει πιο γρήγορα” η εφαρμογή που συντηρούσαν, ενώ ταυτόχρονα ο DBA μας ανακάλυπτε πως στη βάση δεν υπήρχε index πουθενά!

– Θεωρία; Αυτά είναι για τους θεωρητικούς. Εμείς εδώ γράφουμε software που δουλεύει!

Αλήθεια;

(next)

MRG32k3a

While reading “The Skein Hash Function Family“, I saw that Skein can be used as a PRNG. This reminded me three things: First, of MIT AIM-36 “On the Effective Definition of Random Sequence“. Randomness can be so tricky.

Second, at the the WNS2 workshop where George Riley presented his tutorial on NS-3, he mentioned that they were using L’Ecuyer‘s MRG32k3a as their PRNG. MRG32k3a is described in “Good Parameter Sets for Combined Multiple Recursive Random Number Generators” and reference implementations are available. L’Ecuyer has also written an easy introduction to random numbers.

Third, and as a reminder to Panagiotis, this must be the weirdest book that a man can have on his library: A Million Random Digits with 100,000 Normal Deviates. I will order it some day.

Update: For true randomness visit random.org.

exit strategy

Ο manager της χρονιάς (κανονικά) δεν εγκαταλείπει στα δύσκολα. Αντίθετα κάθεται και αγωνίζεται να τα βγάλει πέρα. Φαίνεται όμως πως για μερικούς η επιτυχία έχει πατέρα τον manager και η αποτυχία τον κόσμο…

Ούτε καν το Μάιο όπως υποσχέθηκε.