<< A Vicious Triangle of Organisational Conflict | Home | Art & Code: e ora divertiamoci >>

Tra un buon programmatore e uno ottimo

Beautiful old lady from Darap(Sikkim) village




Ogni buon programmatore sa risolvere un problema difficile aggiungendo complessità
Solo un ottimo programmatore sa farlo semplificando


Bel principio !  Come metterlo in pratica ? Per esempio ...


- Non confondere un sintomo con la causa principale del problema. Puoi verificare con i 5 perchè e la root cause analysis. E affronta la causa principale ora.

- Lascia la soluzione tecnologica (serve un nuovo tool, serve questa libreria, serve questo prodotto) come 3za opzione

- Prima cerca la soluzione nelle relazione tra le persone (tra i membri del team se é un problema del team, tra gli utenti che usano il sw se é un problema applicativo) per es. nel modo in cui cooperano e si sincronizzano (a qualcuno piace chiamarlo team Work a qualcuno piace Processo)

- E poi cerca la soluzione nelle persone coinvolte nel problema (per es. hanno tutte le info, hanno bisogno di migliorare i propri skill, di fare formazione?)

E qui un esempio pratico di una soluzione tecnologica che affronta il sintomo, trascura la causa principale e aggiunge complessità: guarda il video  :D


Tags :   |  |  |  |

Print | posted @ giovedì 9 luglio 2009 16.07

Comments on this entry:

Gravatar # re: Tra un buon programmatore e uno ottimo
by Alessio Marziali at 09/07/2009 16.56
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction"

Albert Einstein
  
Gravatar # re: Tra un buon programmatore e uno ottimo
by LudovicoVan at 09/07/2009 21.46
Non si tratta di una esortazione generica e differisce nella *sostanza* dalla massima di Einstein: nella nostra professione (produzione di software), si razionalizza il dominio del *problema*, abbassandone il piu' possibile il livello di complessita'.

Luca, mi piacerebbe citare la tua massima: e' proprio tua (magari davvero una parafrasi di Einstein), oppure avresti una fonte da darmi?

Thanks,

-LV
  
Gravatar # re: Tra un buon programmatore e uno ottimo
by LudovicoVan at 09/07/2009 21.57
> Bel principio ! Come metterlo in pratica ?

My take:

E' il dominio del *problema* l'ambito in cui la complessita' va tenuta bassa, che e' appunto un principio che deve informare il processo di razionalizzazione.

La complessita' concettuale del prodotto e tecnologica, quindi relativa al dominio della *soluzione*, dipende direttamente (e solo!) dalla complessita' del *problema* come ridotta (o non ridotta) al passo precedente.

Infine, la complessita' intrinseca al dominio *tecnico*, cioe' al processo di produzione, e' invece indipendente (ortogonale) dai punti precedenti, e si parla piuttosto di rischi tecnici piu' che di complessita' in senso stretto.

-LV
  
Gravatar # re: Tra un buon programmatore e uno ottimo
by Luca Minudel at 09/07/2009 22.34
ho provato a descrivere una idea con parole mie, non credo sia nienete di nuovo cmq

x fare un esempio pratico, in un piccolo team il sw ha troppi bug e una proposta è quella di assumere un tester per passare il sw al QA prima della analisi o un tool di test automatici

osservando i tipi di bug (errori anche ingenui di programmazione) , la dimensione del team (5 persone) e il software (semplice e non critico) la scelta smart è quella di far lavorare i dev in pair (gli errori di distrazione diminuiscono) e fargli un po di training di programmazione o sostituirli con dev più capaci
  
Gravatar # re: Tra un buon programmatore e uno ottimo
by LudovicoVan at 09/07/2009 23.13
> ho provato a descrivere una idea con parole mie, non credo sia nienete di nuovo cmq

A mio avviso, le pratiche che descrivi rientrano in un'ottica orientata ad una qualita' agile e sicuramente smart (del processo).

D'altra parte, il principio di mantere bassa la complessita' si riferisce ad altro, ovvero alla razionalizzazione del dominio del problema che si fa in sede di analisi.

Questa distinzione penso che sia importante da capire, perche' e' solo al livello di analisi che si decide il destino del progetto in termini di complessita' (del problema).

-LV
  

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 3 and 7 and type the answer here: