Avventure e disavventure dal mio piccolo universo

lunedì 21 dicembre 2009

Technical debt

In un mondo perfetto non ci sono Technical Debt (TD). Ma noi non viviamo in un mondo perfetto e e questo non è un male!

Le (mie) tre vie al TD:

- Lo si compie inconsciamente e non lo si riconosce
- Lo si compie consciamente e lo si ignora
- Lo si compie consciamente, lo si valuta e lo si annota (è di fatto un bug)

Noi viviamo di TD perché se non ci fossero vorrebbe dire semplicemente che abbiamo costruito un sistema perfetto, che non esiste, quindi lo sforzo più grande è capire quando ci si deve fermare.

Un esempio di TD ambiguo é secondo legato agli aspetti di Premature Optimization (PO: la radice di tutti i mali); eppure nel fluire del codice dalla nostra mente al nostro editor di fiducia occorre ignorare il TD per non incorrere nella PO.

Certo identificare un TD a livello micro è forse scorretto e va contro la logica del TD, ma la stessa cosa si può applicare salendo di livello al design: se decidiamo di implementare una funzionalità utilizzando una tecnica semplice e inefficiente al posto di una complessa e efficiente (assumendo che l’efficienza sia un requisito) abbiamo un TD, d’altra parte sforzarsi prematuramente per rendere del codice efficiente già a partire dal design ritorna ad essere una PO.

La chiave di tutto deve naturalmente essere il contesto e l’analisi dei tradeoff che si hanno quando ci si trova a scegliere una strada piuttosto che un’altra quindi se da una parte occorre combattere l’ignoranza (propria o degli altri) che causa TD senza accorgersene, educare o educarsi all’analisi dei tradeoff è un requisito altrettanto fondamentale.



Inspired by:
http://blog.objectmentor.com/articles/2009/10/15/we-must-ship-now-and-deal-with-consequences
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html
http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt

Must learn: tradeoff analysis

venerdì 18 dicembre 2009

Feature Teams

Il modello dei Feature Teams (FT) è veramente interessante: l’approccio verticale può dare grandissimi vantaggi eliminando molti problemi che normalmente si hanno utilizzando Component Team / Layer Team.
Se i vantaggi sono chiari resta ancora da capire quali sono gli aspetti negativi, soprattutto ad esempio per un’azienda orientata al prodotto. Per cercare di evidenziare i problemi cercando di ragionare ho individuato almeno tre aspetti critici che vanno approfonditi.


Come si relaziona FT rispetto al middleware

Il middleware dovrebbe essere ragionevolmente intoccabile, se il middleware è esterno la cosa è relativamente banale essendo un componente non ci sono problemi di sorta. Se il middleware è sviluppato internamente si potrebbe essere tentati dal coinvolgerlo nella feature, magari perché una piccola modifica allo stesso potrebbe portare grossi benefici alla feature in termini di design e effort ( a patto che non si carichi il middleware con aspetti funzionali nel qual caso sarebbe comunque un errore).
Probabilmente l’approccio più corretto è quello quindi di considerare il middleware un componente chiuso, inserendolo semplicemente nello Stack di progetto e convivendo con i suoi limiti. Ma a questo punto la domanda è come si fa a gestire il middleware con un feature team.

Come si relaziona il feature team rispetto al design del layer / componente

Ragionevolmente se FT tocca i vari componenti si crea un problema di coerenza a livello di design del layer/ componente. Il problema andrebbe forse contestualizzato maggiormente, ma giusto per fare un esempio, FT potrebbe voler implementare una nuova funzione in un layer, questa funzione potrebbe essere molto vicina ad una già presente ma non sufficientemente generalizzata, FT aggiunge nuovo codice senza conoscere le altre componenti e quindi potrebbe creare una duplicazione di codice inutile al posto di un refactoring che porterebbe maggiori benefici (meno codice, più generalizzato). Si può mitigare il problema definendo un owner del componente che possa sovrintendere la crescita del componente partecipando al FT. Ma mi pare un controsenso, in questo modo si aggiungerebbe uno strato orizzontale portando di fatto ad avere una matrice che difficilmente è produttiva.

Skill del FT

Il feature team deve ovviamente conoscere bene la funzionalità, questo è un bene, ma come fa a conoscere tutti i tool , gli ambienti di sviluppo, gli hack specifici che solo un component team può conoscere condividere e rinforzare. Ancora una volta la soluzione sembra essere quella di aggiungere una responsabilità orizzontale, tornando al problema di prima.



Senza dubbio il concetto dei Feature Teams è molto potente e tende a risolvere un’ampia gamma di problemi (soprattutto di integrazione, ma anche di minore overspecification). Bilanciando la resistenza al cambiamento e la sua forza nel cercare di fare fallire gli stessi rispetto ai benefici non sono ancora certo che si possa applicare facilmente con successo.

Prossime letture sull’argomento:
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum


Inspired by: http://www.infoq.com/articles/scaling-lean-agile-feature-teams

mercoledì 16 dicembre 2009

Smettiamo di usare Flash (o almeno usiamolo solo quando serve)

Uso un computer piuttosto veloce quindi mi stupisco sempre quando vedo una grossa occupazione di CPU o qualche strano rallentamento. La maggior parte delle volte una veloce verifica, basta il Task Manager, mi porta ad individuare il colpevole: uno dei vari browser che uso abitualmente (almeno 3 diversi con varie finestre aperte). Individuare la pagina responsabile é un attimo basta cercare quelle con le bellissime animazioni Flash che decorano le pagine più visitate sotto forma di ads. Non ho nulla contro gli ads e anzi mi piace molto la loro profilazione , ritengo anche che ricevere pubblicità mirata sia meglio di ricevere pubblicità generalizzata troppo spesso inutile. E mi piace la pubblicità perché è uno dei tanti modi che mi fa scoprire le cose, non è raro che quindi deliberatamente segua e approfondisca alcune indicazioni commerciali.

Quindi chiarito fatto che la pubblicità in quanto tale non mi dispiace, arrivo al problema vero: perché la mia CPU deve lavorare al massimo per gestire la pubblicità? NO questo non è accettabile, la CPU mi serve a fare altro e se non mi serve preferisco che rallenti e provi a risparmiare un po’ di energia piuttosto che essere occupata a gestire le animazioni degli ads.

Alcuni siti come StackOverflow espressamente rifiutano inserzioni pubblicitarie animate (grande Joel! ), questo è encomiabile, ma non basta occorre fare di più.

Quindi ora mi sono rotto, e ho deciso di iniziare a usare flash deliberatamente e smettere di subirlo.
Non essendo l’unica persona sensibile al problema posso contare sul valido aiuto dei miei compagni di sventura che hanno non solo colto prima di me questo problema ma che si sono anche adoperati per risolverlo.

Ecco ciò che ho fatto io con il loro aiuto:

Chrome: estensione Kill-Flash: é la più pratica e funzionale, anche se ovviamente occorre usare una versione di Chrome abilitata alle estensioni (al momento uso 4.0.266.0)
Firefox: estensione FlashBlock
IE 8: Toggle Flash non é per nulla funzionale ma per ora mi accontento. Se qualcuno ha suggerimenti sono benvenuti.

Spero che ora la mia CPU abbia un po’ di pace o, come minimo, che sia io a sfruttarla deliberatamente.

Mi piacerebbe lanciare una nuova campagna del tipo:

Stop animated Flash Ads
Let your CPU sleep



Ma mi manca ancora una bella animazione Flash da poter distribuire ……