[AcLab] 8 months in Microsoft, I learned these

[Federico Razzoli]

Post interessante:
http://ahmetalpbalkan.com/blog/8-months-microsoft/

E' interessante perché l'autore dice che non si tratta di problemi
specifici di Microsoft, ma di tutte le grandi società. Io non ho la minima
esperienza per dire se questo sia vero o no, mi limito a leggere
un'opinione.

Se è effettivamente vero, qualche commento...

* La maggior parte di questi problemi, ma non tutti, sembrano identici ai
problemi delle piccole società.

* Alcuni di questi problemi, ma pochi, nelle piccole società non li vedo.
L'autore dice che può passare una giornata intera senza un commit, e che
in un giorno passa due o tre ore a programmare, mentre il resto sono
attività collaterali e riunioni. Ecco, nelle piccole società è esattamente
il contrario: le ore che passi sul codice sono almeno il 120% del tuo
orario lavorativo teorico. Naturalmente c'è bisogno anche di riunioni; ma
prima che il tuo capo riesca a darti un'informazione banalissima (tipo sì
o no) che per te è vitale, può passare una settimana. Durante la quale si
lamenterà senza vergogna del fatto che ti aspetti qualcosa da lui, e farà
di tutto per sfuggire alle sue responsabilità.

* Alcuni di quei punti, non so come funzionano nelle grandi corp, ma nelle
piccole società dipendono dalle persone. Perché gli individui hanno ancora
qualche voce in capitolo, anche se prima o poi il capitalismo riuscirà a
eliminare questa seccatura. Penso in particolare alle code review; certo,
anche i piccoli le considerano un'inutile perditadi tempo. Non esiste un
numero di bug critici che per i manager è un prezzo troppo alto, se sono
stati introdotti per lavorare più in fretta, e risparmiare magari un
giorno di lavoro. L'importante è che, quando incontri il cliente, il
bottone funzioni; se nella vita reale nessuno riuscirà mai a sfruttare
quella funzionalità, questo non ha la minima importanza per i manager.
Però, come dicevo, gli individui possono portare avanti un'altra linea di
pensiero. All'inizio nessuno li ascolta; la bravura è impostare le cose in
modo che, quando un cliente ti molla, tu possa dire "io però l'avevo detto
che dovevamo fare così e cosà". Le prime volte continueranno a non essere
ascoltati e saranno il capro espiatorio. Ma a un certo punto, il manager
avrà due possibilità: arrendersi all'evidenza che tu hai ragione e lui
"ragione" non sa nemmeno cosa voglia dire, oppure far fallire la società
tenendosi la magra consolazione di dire "è colpa tua". Arrivati a questo
punto, un po' alla volta, puoi riuscire a imporre un modo di lavorare
diverso. Per esperienza, puoi arrivare a imporre test di accettazione di
tutti i tipi (unit test, system test e perfino analisi statica del codice)
a una società che prima diceva: "se trovi il modo di farlo funzionare
davanti al cliente, abbiamo finito".

f.