Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register


Priorities

Priorities. What a nice word. It's a pity that whoever is using it, more often than not has no clue about the meaning of it. Or better, he has, but most of the time in the sense that he think it means "what I want is a lot more important than what you or everybody else want". And since this is the standard modus operandi, there are always conflict between what the things that should be done, what can be done and what is actually done.

For example, a long, long (ok, not THAT long) time ago, a nice end-of-december day, I was in the office (what were you thinking?) and was busy installing a brand new server that should've replaced an old (and severly under-sized) one during the festivities, when the guy that was going to become "dumboss", decided that a customer's request to get some sort of usage statistics about something I don't know anymore was a lot more important than the new server.

Since the request was quite convoluted I asked what kind of statistics they wanted, but he had no clue, what he knew was the the request had more "prio" than everything else dammit! So I decided to call directly the customer and ask them, but I got told that they didn't knew also and the guy that did the request originally was in holiday until the new year. So much for "priority".

All this to introduce $asses&dumb, a known company that... I have no idea, in any event, these peoples had (and probably still has) a nice interwebsite, used for... again I have no clue (just to tell you how known it was and probably still is).

Some of the functionalities of that site were "back-office" oriented, so they were not meant for the general public but only for internal use, while other were for general use. And it happened, a lot in fact, that in doing changes and updates to that thing, one or more of those features got hopelessy fucked up.

Obviously, the very same features were "mission criticals" and as such monitored 24x7, and also obviously they tended to go pear-shaped for unknown reasons between 01.00 and 03.00 at night, waking up the poor asshole in stand-by. And since they were mission-critical, we had no such thing as a clear "escalation" procedure and no way to notify the developers of that gigantic pile of smelly stuff that their baby was, again, fucked.

And, again, obviously, the next morning we had $asses&dumb at the phone yelling that this-or-that thing was broken and they didn't got informed.

The process was usually the following:

1. Developers implements feature "X" in the application.
2. Feature "Y" (theoretically independent from "X") stop working.
3. Developers start working on function "K" that has more "prio" than "Y" that is broken.
4. Feature "Z" begin to fail.
5. Multiple mails and phone calls from $asses&dumb about "Y" that doesn't work, multiple answers on our part that we can't fix it.
6. Developers finish "K" and begin to look at "Y".
7. "Y" is somehow fixed, no idea what was the problem or how it got fixed.
8. "Z" fails completely but we got told that is no longer in use but we still need to monitor it 24x7.
9. Developers begin to work on "Z".
10. Developers stop working on "Z" that is no longer 'priority' and begin to work on a new feature named "W".
11. go back to 1.

After several loop, we ended up talking with one of them, around point 5.5...

UL - ...so we want to know why Y keep giving erros.
Me - And I told you multiple time that the error is an application error, so it's your developers that need to check that, we can't fix it.
UL - But our developers now are busy fixing a problem that has an higher priority!
Me - Well, you decide your own priority, we can't do much about it.
UL - But we need Y! It's mission-critical! Even more!
Me - Again, that's your priority not ours. We can only report that Y is broken, not fix it for you. But, just out of curiosity, what are your developers working on that is so important?
UL - If you go to www.asses.dumb.com/thisorthatpage you see that the picture is not alligned with the text.
Me - ...not alligned...
UL - No, it disrupt the whole flow of the page! It has to be fixed.

...priorities... somebody has them... somebody else make them up at the moment.

Davide
26/09/2018 11:49

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

4 messages  this document does not accept new posts

Messer Franz

By Messer Franz posted 05/11/2018 09:38

Ammetto che non mi ricordo dove nel tuo sito l'ho letta, forse era una storia tua forse di qualcun'altro, ma quando hai scritto

>UL - Se andate su www.scalchi.mani.com/questaoquellapagina vedete che l'immagine a destra non e' allineata al testo.

IO - ...non e' allineata all testo...

UL - No, sballa tutta la simmetria della pagina! Deve essere corretto subito.

 

Mi sono ricordato di quella in cui c'era da correggere un terribile errore ed era il colore del banner...

ps: io sono un programmatore c++, che ultimamente bestemmia anche contro lo GNU, che di per sè per il web usa php (ma i miei siti funzionano), quindi quando parli male del php io penso a programmatori cani (che ce n'è fin troppi in giro), ma non penso particolarmente male del php. Adesso però il web da queste parti sta passando dal phpchesenonsaiusarloincasinitutto al C#cheincasinadibaseecongrandeefficenza.

Non hai idea dei siti che vedo, i programmatroti php non arrivavano a questi livelli se non con grande impegno.

Anche dalle tue parti succede così?

-- Messer Franz

Lazza

@ Messer Franz By Lazza posted 13/11/2018 01:01

> quindi quando parli male del php io penso a programmatori cani (che ce n'è fin troppi in giro), ma non penso particolarmente male del php.

Ma PHP è effettivamente male proprio dal punto di vista del linguaggio. Purtroppo molte caratteristiche che lo fanno sembrare facile/bello in realtà sono la punta dell'iceberg che si compone di enormi errori di progettazione (come ammesso dallo stesso creatore di PHP).

Pure io da ragazzino pensavo che PHP non fosse male, poi per fortuna ho dovuto studiare per l'esame di linguaggi formali e ho messo la testa a posto. :D

PHP si può usare in modo corretto, certo, ma si presta benissimo a essere usato da cani. Con lo spopolare di sviluppatori "self-taught" (che va tanto di moda negli ultimi anni), il fenomeno si è moltiplicato a dismisura.

Se posso dare un consiglio, per dover subire meno PHP prova a usare Flask (un micro-framework basato su Python).

-- Lazza

Guido

By Guido posted 06/11/2018 07:49

Priorita'... qui in $ENTE_PUBBLICO (di cui ci tengo a precisare non sono dipendente) significa: fai per ieri quello che hai iniziato tre mesi fa, interrompendo quello che stai facendo in questo momento (che ti avevo detto urgentemente di fare) e che ti faro' riprendere in mano (sempre urgentemente) quando te ne sarai dimenticato.

-- who uses Debian learns Debian but who uses Slackware learns Linux

Anonymous coward

By Anonymous coward posted 06/11/2018 21:28

L'ultima volta che qualcuno disse al mio capo: "è urgentissimo, è una priorità" si sentì rispondere: "ok, mo' costruisco dei fantocci e ci guardano loro"

-- Anonymous coward

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project Powered By Gigan