When will it be done?

– You say estimates; I hear deadlines

We all know the system administration rule of thumb about when a task will be done:

Estimate the time it will take you and double it. Then double it again and add some more.

This is not a baseless rule. You know how much it will take you to finish the task. What you cannot predict in this interrupt driven line of work that we do, is how much noise you will have to deal with simultaneously while dealing with the task at hand. Or what unexpected circumstances will unearth because of misinfromation, poor documentation or simply bad luck. So you need breathing space in order to complete the task. For when you give an estimate, users take this as written in stone. When you are of your estimate they view this as a broken promise, regardless of what caused the extra delay. They just do not care. All they care about is that you “promised” it will be ready at some time and it is not. And because they do not care, you always need more time than you think.

Sometimes this also has the added advantage that when you are lucky enough to work uninterrupted and finish within the time frame promised, polite users will thank you for your efforts to complete as fast as you could. They see this as a proof that you care about their pain and do your best. Oh, yes the rest again do not care.

Why was I reminded of this? Well because our DBA hang on his wall the following formula:

T_c = \frac{b + 4m +w}{6}

Where Tc is time to complete, b is the best time, w is the worst time and m is the most likely time. You can read more about the formula and its history here [pdf].

A junior DBA discovers consulting

After reading this (in Greek) a friend, who works as a junior DBA at a bank, sent me these dialog exchanges between him and a highly costing consultant:

  • Friend: I think that rebuilding the indices once a week just because this works is not the proper method to deal with the problem. Shouldn’t we be looking at other stuff like table fragmentation for example?
  • Consultant: Look, rebuilding and reorganizing the indices once a week is good practice because you know, it works!

Two years pass and:

  • Consultant (the same): In order to be sure when to rebuild the index, you should look at the table fragmentation level.

By the way, if someone is interested in a junior DBA who can put in the hours needed to solve problems and is not afraid of studying in depth in order to do so, drop me a note so that I can put you in touch.

So long and thanks for the fish

Mark Reed Crispin, inventor of IMAP, passed away on Friday, December 28, 2012 at Martha and Mary Healthcare Services in Poulsbo Washington. He was born on July 19, 1956 in Camden New Jersey and was 56 years of age.

Very few people have (almost single handledly) designed protocols and implemented (free) software that has facilitated communication among millions of people. Mark was one of them and thanks to his monumental achievement of IMAP (and the fact that the Net cannot “forget” his posts on comp.mail.imap) he will always be remembered and always there to teach those who want to hear him.

As someone who has had the privilege to exchange personal emails with him, I am deeply saddened by his departure. I think he is the first of my email heroes that leaves.

Space Pen, μολύβια και άλλες “έξυπνες” λύσεις

Ξεκινάς το άρθρο σου γράφοντας:

Λ​​έγεται ότι όταν πρωτοπήγαν οι αστροναύτες στο Διάστημα, διαπίστωσαν ότι δεν μπορούσαν να γράφουν με τα στιλό διαρκείας λόγω της έλλειψης της βαρύτητας […] Οι Αμερικανοί, ύστερα από έρευνες που κοστίσαν πολλά εκατομμύρια δολάρια, κατασκεύασαν ένα στιλό με εσωτερική πίεση που μπορούσε να γράφει κάτω από οποιεσδήποτε συνθήκες, ακόμα και στο Διάστημα. Οι Ρώσοι, όταν διαπίστωσαν ότι έχουν το ίδιο πρόβλημα, εφοδίασαν τους αστροναύτες τους με μολύβια

Το στυλό της ιστορίας είναι το Space Pen. Το πρόβλημα της ιστορίας είναι πως “οι Αμερικάνοι” (η NASA στη συνήθη εκδοχή) του μύθου δεν επένδυσαν σε αυτό εκατομμύρια δολάρια ποτέ. Και αυτοί μολύβια χρησιμοποίησαν στην αρχή και όταν o Fisher έφτιαξε το space pen, το χρησιμοποίησαν τόσο οι Αμερικάνοι όσο και οι Ρώσοι. Δε χρειάζεται να ξέρεις πως οι Πολεμικές Αεροπορίες ήταν οι πρώτοι που έκαναν μεγάλες παραγγελίες για ballpoint pens ώστε να καταλαβαίνεις πως το μολύβι δεν είναι η έξυπνη λύση στο πρόβλημα γραφής σε αντίξοες συνθήκες. Γιατί να χρειάζεται άλλωστε όταν γράφεις:

Δεν γνωρίζω αν η ιστορία είναι αληθινή ή κατασκεύασμα του Ψυχρού Πολέμου

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

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

Ah the feedback loop …

And modelers rarely if ever consider the feedback loop and the ramifications of their predatory models on our culture.

This does not happen with modelers only. It happens with everyone that has a “good idea” and rushes it forward without really thinking whether it will work or not, and how long afterwards we are going to see how what was introduced interferes with what was already there, fine tuned and working. And that is why I read about cybernetics; not because it is less obscure, or more useful than people think, but because it always reminds me of the feedback loop.

investigators are part of the system
investigators are part of the system

→ Homeostasis from a sysadmin perspective.